Paste: how to sub-type in clay
| Author: | guest |
|---|
| Mode: | text |
|---|
| Date: | Tue, 19 Oct 2010 05:39:19 |
|---|
Plain Text |
first i must distantiate myself from being a crack in clay.
i am rather the functional guy with oop-experience. possibly all of the below is nonsense. please teach me a
better insight!
common programming languages base on the idea of providing
very basic types to derive from them. derivates are
commonly layed out by using compound types (arrays,
records, structs...). but there is a special case that is
not well focused by most programming languages. often a set
of types is so homogenous that implementing the types - and
the necessary api's - individually would be overkill.
instead, a basic container type stores the higher types as
data sets, as if they were virtual types. simple examples
are multidimensional versions of types or basic template
types etc.
the virtual types are mainly treated via the real type's
api, except of case-wise extensions. this api must do
runtime checks for orientation, causing speed loss but also
memory overhead because the meta-data. runtime checks can't
securely detect specific (accidential) alterations of the
meta-data, like when a virtual type's identity was
overwritten.
in clay the situation should be far better because of
strong typing and compile-time predicates. the compile-time
evaluation should allow more subtle distinction than in
primitive languages, and it generally does. however, clay
doesn't seem to have a clever strategy for, say,
sub-typing. the only way known to me to make the virtual
types distinct at compile-time is to extend them to real
types. this strips the original interfaces and thus
compatibility, which can be re-gained by redundant or
complex forwarding.
i wish to see sub-typing in clay - without relying on more
complicated strategies like inheritance. one possible way
is to extend "versions" of an original type by sharing an
internal pointer to the original type's predicates and
interfaces and downgrading the types to the original type
when following the pointer. another solution is "tagging"
of instances of the original type to make them distinctable
via a predicate like isTagged?(T,Tag) without extending a
new type and stripping all original interfaces. the only
problem (except of implementation) is that an extended api
should be able to inline and overgive values to overloaded
original functions. one solution to the latter is to "hide"
the tag via a special function like in index(noTag(x),12).
the instance will find its way down to the original
function, i guess.
possibly there is an even easier way but i don't know any.
what do you think?
| Author: | ksreeram (cited by guest from chat log) |
|---|
| Mode: | text |
|---|
| Date: | Tue, 19 Oct 2010 12:16:03 |
|---|
Plain Text |
guest, I understand sub-typing is a popular feature in many
other programming languages, but Clay doesn't have it. I
personally find sub-typing to be an unsound feature in the
presence of mutation. And, mutation is definitely a far more
important feature than sub-typing. If you do have a very
practical and concrete use case for sub-typing where Clay's
other features don't suffice, then I will think about it.
| Author: | guest |
|---|
| Mode: | text |
|---|
| Date: | Tue, 19 Oct 2010 13:28:52 |
|---|
Plain Text |
i think that you both don't hit the point. yes, qx, i agree
that extending the vector type is not a good idea. but, if
you remember, i first asked you about the existence of
isAlias?() before i tried to derive a MultiVector (in face
of not having a different solution.)
ksreeram, i guess that i can't show you a 'very practical
and concrete' use case (to just fill a gap in the language)
because the types i'm talking about are generally
understood as being patterns, and thus data, rather than
types. in oo-languages they could be derived classes but
that's a different point. the point is that i don't know
how to use the powers of compile-time predicates on
patterns.
patterns are no types in terms of programming languages
though they are handled very similar - at runtime. think of
basic polygons for drawing or of basic text templates
with placeholders for quick website creation. all these
'types' of patterns have one thing in common: they very
often fit into a simple storage type, profit from its given
interface and only need a small selection of extra handlers.
only because they must be distinctable and configurable
they are rather implemented as own types or as pure data
accompanied with meta-data and stored in a struct. however,
that's not the generic way.
in clay, i'd implement the pattern types and the
configuration types separately because the configuration
types (for color etc.) can also be used generically. the
only left 'redundancy' is the identifier. that's the point.
if i could turn that identifier into an alias and check for
it with isAlias?(), the struct could be dropped, and
overloading the storage-type interface would do the job -
at compile-time. this is the efficiency i want to gain from
clay. otherwise i'm forced to create runtime overhead
without a hard reason.
if you know a better way to reach this goal, i'm fully open.
New Annotation