Hugh,
This slot used to be for the tuple delegate before delegation was removed
after inheritance was added.
http://factor-language.blogspot.com/2008/08/three-language-changes.html
http://factor-language.blogspot.com/2008/09/improved-tuple-literal-syntax.html
-Adam
On Mon, May 18, 2009 at 5:42 PM, Hugh Aguilar <[email protected]>wrote:
> Thanks for the tip on parameterized constructers; that did help. I think
> that I should have been using new rather than boa. I have I changed symtab
> and it is uploaded to the website if you want to look at it:
> www.rosycrew.org/symtab.factor. I also fixed a bug in optimize that I
> discovered.
>
> There is one strange thing that puzzles me. When I use new to create an
> object, I get an extra slot in the front. What is that? My tuple looks like
> this:
>
> TUPLE: symtab key count left rite ;
>
> When I create one with
> symtab new
> I get this:
>
> T{ symtab f f f f f }
>
> Notice that there are 5 slots, rather than the 4 that I would have
> expected.
> I have the following code to initialize the tuple:
>
> : <init-symtab> ( key initial-count node -- node )
> 0 >>left
> 0 >>rite
> swap >>count
> swap >>key
> ;
> inline
>
> : init-symtab ( key node -- node )
> 1 swap <init-symtab> ;
> inline
>
> When I create a tuple like this
> "simple" symtab new init-symtab
> I get this:
>
> T{ symtab f "simple" 1 0 0 }
>
> Notice that my 4 slots are initialized (key="simple", count=1, left=0,
> rite=0), but we have a mystery slot in the front that is set to f. This
> doesn't prevent the program from running, but it seems to be wasting
> memory,
> and it is confusing me. The boa function did the same thing, but I just
> didn't notice it previously. Any idea what that slot might be?
>
> > Message: 7
> > Date: Fri, 15 May 2009 14:17:54 +0900
> > From: Matthew Willis <[email protected]>
> > Subject: Re: [Factor-talk] OOP tutorial
> > To: [email protected]
> > Message-ID: <[email protected]>
> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> >
> > Hugh,
> >
> > I think you should look at "Parameterized constructers" in the help to
> > answer your question about arranging parent/child constructors.
> >
> > About overriding the methods of the parent class: just define a method
> > for the child class.
> >
> > From my experience with OOP in Factor, nearly all code is written as
> > "external functions" rather than "member functions". Methods are used
> > only in the case that code needs to dispatch based on the type of an
> > object. These dispatching words are "low-level" in the sense that
> > words that call them don't need to involve dispatching and hence tend
> > not to be methods.
> >
> > The point of Factor OOP (to me) is to allow one to quickly write code
> > that does different things for different objects while not forcing one
> > to write extra boilerplate for non-dispatching code.
> >
> > Have fun!
> > Matthew Willis
>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Factor-talk mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Factor-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk
