retry: hybridizing classes and prototypes

retry: hybridizing classes and prototypes

Post by cr8819 » Sun, 21 Nov 2004 12:19:51


[I am thinking the original version was lost in transit, I appologize if
this is a duplicate].


ok, so I have a kind of javascript style language that inherits a lot of
features from languages like scheme as well. syntax is no-longer fully
transparent, more syntax->opaque xml->syntax, and can't really, eg, be used
in the same way as in scheme. oh well, but I have quote and eval at least
(along with some kludgy stuff for binding "pattern" variables in expressions
or similar).
I also have a crappy macro system, oh well...

now, other things are showing themselves as wanting to be implemented, eg,
psuedo-static typing, more of the compiled variant, ...

eg: the issue of classes vs. prototype objects.
classes are ridged and can't really be changed at runtime;
prototype objects lack a true "type", and faking one seems inelegant (is
this object just a prototype object, or some other self-described type?...).
similarly, the concept of "type" is necessary for many features (eg:
operator overloading, multiple dispatch, ...).

other issues are things like special properties for slots/methods,
constraints, ... which seem almost to require at least partial classes and
psuedo-static typing (constraints are possible in pure dynamic typing, but
often the semantics seem a little dubious imo).

so, this is possibly a change for my language, it may shift from being
purely dynamic to a weird hybrid eventually. declaring types may have uses,
but will in many cases be optional.


local x; //x can hold anything
local x:int; //x can only hold integers

also possible is "joint types", eg:
local x:int|NULL; //x can be either an integer or a null value
however, these add complexity.


classes may allow a good way to dispatch based on object type and
inheritence graph (as in many class-based languages). as opposed to just the
value of a "classname" slot.

a question is how to merge them with prototype objects.
the idea I guess is that:
any object is an instance of some class;
objects can be instanced from classes, or cloned from another object (they
retain the parent object's class);
delegation has no effect on class, but does still effect what is visible
(dunno whether the delagation or class graph should be higher priority,
leaning twards class graph, as implicitly all class slots would be defined
in the current object).

explicit assignment of unbound slots can still create slots (I guess by
default public and dynamic). implicit assignment of unbound slots (as is the
case allready) is in error.

eg:
self.foo=3; //creates a slot if not present
bar=4; //is in error if bar doesn't exist


I am considering only having single inheritence, and whether things like the
'new' keyword should be necessary.

class Foo:Object {
function Foo(sbar, sbaz)
{
bar=sbar;
baz=sbaz;
}
function ~Foo() {}
function GetBar()bar;
function GetBaz()baz;

private bar;
private baz;
}

or should I use a style more like 'class Foo extends Object { ...'?

now, do I use:
var foo_obj=Foo("bar", "baz");
or:
var foo_obj=new Foo("bar", "baz");

such decisions (the former makes sense, and doesn't need a keyword), but the
latter is more obvious, and allows checking for obvious problems (like class
"Foo" undefined). hmm...


this could work, dunno. all of these would be signifigant wrt semantics.

oh well...
 
 
 

retry: hybridizing classes and prototypes

Post by gabriele r » Mon, 22 Nov 2004 18:26:05

cr88192 ha scritto:


why don't you go the way ruby or smalltalk do?
I.e. classes are there, but you can always change them, and you can add
a method an or instance variable to almost any object. This makes hard
to establish
that
foo(SomeClass s) { s.doStuff() }
always works, since doStuff may be undefined... but..

> (eg:
> operator overloading, multiple dispatch, ...).

.. if you choose to define the 'type' check for MMD and operator
overload as a predicate check everything works again, and you can have a
more general solution (and even rely on prior work, lots of papers
about efficent predicate dispatching)




scheme and lisp both allow type hints like this. It is a nice thing imo.


if you have classes that are objects, and rely on predicate dispatch you
can think of defining a standard method like
Class.check(object) if object.is_a Class then true else false
and an operator Class.| that returns a special Klass where
Klass.check(obj) if obj.is_a Class or obj.is_a OtherClass true else false

 
 
 

retry: hybridizing classes and prototypes

Post by cr8819 » Tue, 23 Nov 2004 00:52:21

"gabriele renzi" < XXXX@XXXXX.COM > wrote in message
news:NaZnd.43247$ XXXX@XXXXX.COM ...
I was thinking some, and in a post elsewhere I was considering, eg, how
types might be treated by code.
eventually I came up with the idea that they can be used in normal
expressions, but have scoping that is under the control of the compile code.
I had decided to generally, at least, to make info about types immutable by
normal code.

my idea was still sort of a joint-system idea, eg, classes themselves are
immutable, but objects are not (adding new slots and methods is fine).

dunno, I feel unsure about predicate dispatch myself.
however, I am generalizing things such that it may be possible. types are
expressions, and an expression may not necissarily be a type.

lisp, yes, I know.
as for scheme, I think this depends on the implementation.

err, I don't really follow here.

I had started spec'ing how I think things should be implemented.
this is also where the idea of the 'ClassT' notation showed up...


I thought about it more when doing another post elsewhere, and I will paste
it:
----
I am also considering things for allowing working with types, eg, I still
don't have type predicates, casting, or a decent notion of "type" for that
matter (my current idea of 'types are strings' falls a bit short of being
useful). type may also allow other features, eg, a way to specify
serialization of data to/from files or similar.

I am also considering adding classes, for reasons related to things like
dispatch and similar (and the fact that at present I am lacking a good
definition of "object type", or a good idea to define things like
inheritence).
yes, classes are technically unnecessary for a prototype system, but they
wrap up many basic semantics and have their uses, so I may as well add them,
while still keeping the dynamic aspects, delegation semantics, ... from
prototype objects. it will still be possible to fully ignore the classes,
little will change (all prototype objects will thus be viewed as originating
from the class 'ObjectT').

I had also considered 2 operators:
::, as a kind of "cast" operator (similar to but different from the c
concept);
::==, as a kind of type comparison operator.

eg, I am imagining being like:
class FooT:ObjectT {}
class BarT:ObjectT {}

var foo=new FooT, foo2=new FooT, bar=new BarT;

foo::==bar => false
foo::==foo2 => true
foo::==ObjectT => true
bar::==ObjectT => true

I have yet to really decide on the semantics for a cast operator.
I would guess it could convert between similar types, or maybe those it is
defined for. otherwise it could fail.


I am now thinking types are also expressions, so it will be possible to use
types in expressions, have functions which return types, ...
I am unsure, however, whether types should naturally exist in the same scope
as other data, or have it's own scoping.
naturally, I would guess types would be used by value and not name, and
types would themselves have types.

class FooT:ObjectT {
class BarT:ObjectT {}
function isBarP(v)v::==BarT;
}

class BarT:ObjectT {}

var foo=new FooT, bar=new BarT;

foo.isBarP(bar) => false

ObjectT ::== ClassT => true
ClassT ::== TypeT => true
TypeT ::== TypeT => true

maybe the type equality operator would be non-communitive:
A::==B is type of A is B, but does not imply type of B is A

ClassT ::== TypeT =&g
 
 
 

retry: hybridizing classes and prototypes

Post by gabriele r » Wed, 24 Nov 2004 03:34:35

cr88192 ha scritto:

> comments?

well, I'm not sure I grasp all of you reasoning.
That's because I'm dumb, so nevermind :)

Anyway what I grasped is:
- objects are the main characters. They can dictate their own dispatch,
methods and slots
- classes act like templates, and incidentally as types
- classes/types are really macroish rather than objects
- generic expressions can be used as types

If I understand correctly this sounds cool. I'm not completely convinced
that handling them more like macros is better than threating them more
as objects, but these is just IMVHO
 
 
 

retry: hybridizing classes and prototypes

Post by Aaron Gra » Wed, 24 Nov 2004 10:08:29

> comments?

What I think you are implying is Types are not Classes, this is good and
leads to 'Class Signatures' are Types, or 'Type Signatures' to be predantic
!;)

Okay, then what I think you are missing is 'Interfaces', which are just a
short name or implementation of Type Signatures.

Interfaces are good and allow types to have a _contract_. This can be used
to make types more concrete and provide a bridge between Prototypical
Objects and Static/Dynamic Classes.


On 'Multiple Inheritance', I beleieve that MI is very useful in real world
programming allowing Plug-in behaviour which reduces code duplication. I
find MI missing when programming/designing any non trival application or
library.

If you only provide Single Inhertiance then do provide interfaces like Java
does, but this is a half measure and a cop out, imo.


Also, subclasses are not nessasarily subtypes, this is enfored in some
languages but not in others. Separation of Class and Type is essential !

also, consider the following :-

foo: subtype Foo

.v.

bar: subclass Bar

foo is by type or interface, where bar is by inheritance.

Hope this is useful,

Aaron
 
 
 

retry: hybridizing classes and prototypes

Post by Aaron Gra » Wed, 24 Nov 2004 10:25:58

Being able to freeze a Prototypical Object and produce a Static Class would
be good.


Dynamic Classes are a problem unless some form of versioning system for
objects and classes is employed.

Interfaces do seem to offer some help but are restrictive in terms of
extension of application model, then you are into versions of interfaces as
well as versions of classes.


Another older design I had before I descovered object oriented programming
some 20 years ago was to separate data from code by using pattern matching
of applications of functions onto data structures. This would allow
underlying freeform data to be accessed via a class like structure or/and
also fit in with a prototypical object model.

Just my 10 cents worth,

Aaron
 
 
 

retry: hybridizing classes and prototypes

Post by cr8819 » Wed, 24 Nov 2004 13:05:20


well, imo treating them more like macros could possibly make optimizing a
little easier, and goes along with how I have seen classes in other
languages.
 
 
 

retry: hybridizing classes and prototypes

Post by cr8819 » Wed, 24 Nov 2004 13:07:48


ok, I will look into these more.
 
 
 

retry: hybridizing classes and prototypes

Post by cr8819 » Wed, 24 Nov 2004 13:29:14


ok.

hmm...

ok.

I am still thinking about things, and also am getting pulled around in
"unrelated stuff land". I am getting a thouroghly unimpressive amount of
coding done recently.
I guess coding is better for when I have more focus and less random ideas
popping up...

eg: a good portion of a month and little real coding (except for a lib for
some random idea I came up with...).


(strange and disturbing occurance: maggots crawling around on the floor with
little obvious origin).
 
 
 

retry: hybridizing classes and prototypes

Post by Aaron Gra » Wed, 24 Nov 2004 21:50:19

> (strange and disturbing occurance: maggots crawling around on the floor

Have you got wool carpets ? There are sheep fly larve that feed on wool,
*** things.

Aaron
 
 
 

retry: hybridizing classes and prototypes

Post by Aaron Gra » Wed, 24 Nov 2004 22:24:40

> ok, I will look into these more.

There is alot more behind the difference between subtyping and subclassing,
but that is the first edge to encounter, the next is when applied to
functions/methods of a subclass with covarient return types and
contravarient input parameters, being type safe.

I am reading a very good book called Fundementals of Object Oriented
Languages which goes into this area quite deeply; well worth reading. The
first seven chapters are programmer readable, the rest is computer science
graduate level readable. Not really woth getting for the first seven
chapters alone, chapter eight goes into a typed lambda calculus, which is
used throughtout the rest of the book. So I am thinking of doing a few pages
of html explaining "subtyping v subclassing" for semi advanced programmers
and language designers, on the web as I have not found anything else that
explains it simply and is uptodate, which explains this area properly.

You can do a Google on "subtyping vs. subclassing" there are a number of
articals and pdf's

Aaron
 
 
 

retry: hybridizing classes and prototypes

Post by cr8819 » Wed, 24 Nov 2004 23:16:25


dunno.
I have not looked into type systems that much.

hmm, I remember starting to once read a book on type theory, then my head
died on me...

ok.
 
 
 

retry: hybridizing classes and prototypes

Post by Aaron Gra » Thu, 25 Nov 2004 07:14:00

gt;> There is alot more behind the difference between subtyping and

I am just beginning to learn about the subject properly, still near the
starting point.


Yes, alot of it is overcomplicated and far from every day application. I am
trying the middle road approach, on one side remaining dumb enough not to
get away from the everyday programming level while attacking the more
complex theory necessary to see what is really going on with typing. So far
I am doing reasonably well, I just need to put the stuff I am understanding
so far into the form of a document or two and hopefully do a good job of
explaining the stuff. The book I refered to earlier explains things post the
problem so to speak by introducing problems with existing languages then
explaining the solution afterwards which after five chapters gets annoying
as the whole thing could be explained in one or two chapters. Its a good
book though but the last ten chapters, most of thew book involves non every
day programmer stuff like typed lambda calculus which is a bit much for the
every day programmer, and not worth purchasing for the everyday programmer.
I would like to find another source that explains this stuff otherwise I
will carry on and try to put together a document to explain this stuff.

Basically the theory has been know for years but existing languages eg.
Java, C++ have been slow to pick up on it, apparently C# has done a good job
on this allowing pragmatic cases to get at all that can be implemnted within
its domain.

Looking at Java 1.5/5.0/Tiger or what ever Sun calls it, its generics that
get implemented are very limited, you get covarient return types but you
have to implement them explicitly, there is no anchoring. And as I just
discovered you get no 'new T()' construct only 'new C<T>()' so atleast you
get to create collections of T's if you can not create a T generically to go
into that collection. Then you do not get access to static class members on
a generic basis. Both of these are bacause of the 'Polymorphic Object
Generacism' as I call it as opposed to C++'s 'Template Genercism' which does
not try and use the same (polymorphic) one size fits all code.

Looking at C++ now compilers seem to be catching up with the standard, it
looks quite good, supporting covarient return types, but no anchoring, and
not contravarient parameters, oh well, it is still much better than it was.

C# looks like it is worth learning as it seems to have cut the edge of what
is possible to do within its implementation domain, it has the pragmatics.

But Nermerle would look like it is the winner, all apart from the fact it
does not have multiple inheritance, and it is not a systems programming
language, so back to C++ for now for my immediate programming needs, oh well
got a good compiler now that implements the standard properly.

A quick question, are you using Windows or Linux ?

Aaron


 
 
 

retry: hybridizing classes and prototypes

Post by cr8819 » Thu, 25 Nov 2004 12:33:00

"Aaron Gray" < XXXX@XXXXX.COM > wrote in message
news:41a3b673$0$68689$ XXXX@XXXXX.COM ...
ok.

ok.


err, this is beyond me...

I am still using primarily plain c myself...

windows+cygwin.



 
 
 

retry: hybridizing classes and prototypes

Post by Aaron Gra » Thu, 25 Nov 2004 17:15:20

cr88192" < XXXX@XXXXX.COM > wrote in message
news:MhTod.845$ XXXX@XXXXX.COM ...

Your not aware that Microsoft are doing a freeby copy of their Visual Studio
.NET ++ Beta, which compiles native and to .NET platforms ?

Availiable for cost of postage, about 3 dollars !!!

Order online, you do need a Credit/Debit Card though :-

http://lab.msdn.microsoft.com/vs2005/get/order/default.aspx

Much nice than Cygwin, a full GUI based IDE under Windows :)

C, C++, C#, and J#, broarden your horrizons a little bit maybe :))

(If you cannot order it because of credit card probs, I can order it for you
as a Christmas present.)

Hope you are interested,

Aaron