This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Unifying properties


Keisuke Nishida <kxn30@po.cwru.edu> writes:

> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> 
> > Let's say that objects have names.  Isn't it more natural to say:
> >   (name OBJECT)
> > than
> >   (property OBJECT 'name)
> > ?
> 
> Yes, it is.  But it is an upper level of abstraction.  When talking
> about properties, I think a natural way of programming would be:
> 
>   1. I want properties for this type of objects.
> 
>   2. Okay, I can use object-properties.
> 
>   3. Object-properties is not sufficient.  I need a more efficient
>      procedure.
> 
>   4. Okay, I have written procedure-properties.
> 
> So procedure-properties is a special case of object-properties.
> I just thought this should be unified with the existence of GOOPS.
> 
> But when talking about efficiency, I am not sure how much type
> dispatching costs.  If it costs a lot, this shouldn't be unified.
> I have been thinking procedure-properties is there until now because
> it must be really efficient.

Yes, procedure-properties are supposed to be really efficient.  They
are for example used for tracing in the debugging evaluator.  Unifying
properties will make them slightly slower.  But this will be only
slightly, and I think the gain in the improvement of the user
interface is more important.

But my point is that since (name OBJECT) is better than
(property OBJECT 'name), why support it?  Why support properties at
all?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]