Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: pseudo-class inheritance at a price ?

From: chrismorency:videotron:ca at: 7-Oct-2001 23:14

Hi Christian,
> some months ago I worked an a similiar project, you can find my > code at the bottom of this mail. It's not very complete, but it > may inspire you in a way or two :)
Thanks very much for the code, I will certainly look at it. However, my implantation is almost complete...
> I don't believe this to be a big problem. There are other > dialects in REBOL differing from "native" REBOL style and > syntax, e.g. the dialects used for PARSE and VID.
> > 1. new class would be define like this : > > make-class 'class-name [ ... ] > > Inherited class would be define like this : > > make-class/from 'class-name [ ... ] super-class-name > I for a reason decided against a construct using refinements because this > would make reading your code unneccessarily hard: The specification of the > superclass as an argument to a refinement leads to code looking like > Having a special functions for deriving classes eases reading code a lot, > allowing for having 'class and 'superclass on the same line of code:
<code snip>
> What do you think?
Actually I had implemented the construct with and without refinements, but thought it might be easier for developers to use the refinements... I personnally prefer without. I'll change that ;)
> > 2. Object would be instanciated as : > > new-object-name: class-name/new > > > > I'm thinking about adding an automatic initiation method > > that would be call when instanciating an object ! What > > about a destroy method... > Actually, I haven't thought in deep about that, but as long as > REBOL has it's own garbage collector, do we really need > constructors and deconstructors?
Actually, a constructors might be useful to automatically assigned values to properties... as for the deconstructors, it would'nt be necessary..
> > 4. Within class declaration, methods would be define like this : > > method-name: func [value !refinement ref-value] [ ... ] > > > > However, during execution, refinement would be use as usual : > > method-name "a value" > > mathod-name/refinement "a value" "a ref-value" > > I didn't spend effort to allow for method refinements in my OOP-framework, > but IIRC there was a solution to compose function calls with refinements > on the mailing list some time ago which shouldn't be to hard to implement. > > But if your refinement defining syntax differs from FUNC's style why not > rename your FUNC to METHOD, making the difference somewhat more obvious? > Just a thought, so.
Unfortunately, I really can't use refinements as they are currently being defined... I would have to change some implementation in my library, and some of the code of object instance really really redundant... which I try to minimize. Your idea of a METHOD is great... I'll look at it ;)
> Not beeing a REBOL guru in any way you eventually may find some > suggestions in my code :)
I'll look at it with interest. Best, Chris