Re: object-properties

[Maciej Stachowiak <mstachow@alum.mit.edu>]

Ian Bicking wrote:
> 
> 
> All these properties get confusing.  Is there a reason for the
> difference between procedure-properties, object-properties, and
> source-properties?  (and how can I manipulate source-properties?)
> Couldn't they all be implemented as object-properties?
> 

Don't forget sumbol-properties :-)

In my option, symbol-properties should be removed, as they are wholly
redundant with object-properties. source-properties and procedure-properties
have special semantics for some fields, so they ar enot strictly
redundant, but I think the ability to use them as general purpose
information buckets shoudl be removed.

> > I really should look at integrating the auto-resizing hash tables
> > that were worked on on this list a while back, that should make things
> > more useful.
> 
> Hash tables show up a lot -- they are definately worth doing right.
> 

Agreed.

> > > If object-properties stays reasonable fast or something like it can
> > > do the same thing, this would make Scheme/Tcl data integration
> > > fairly seemless (though almost too seemless -- in particular, in-
> > > place mutation like string-set! is quite incompatible with Tcl's strict
> > > call-by-value)...
> >
> > Can you make that actually keep the values as different types properly
> > in sync in light of arbitrary Scheme manipulation?
> 
> Hmmm... I'm not sure how to parse that sentence.
> 

What I mean is, if I modify a Tcl value as one type, do I need to do anything
special to ensure that its value as other types is kept in sync? If I
change the value as a string, will the value as a list, integer, etc
show up properly thereafter?

> Theoretically Tcl should be making copies of things all the time,
> but I avoid that by making sure the primitives all make copies when
> necessary.  This might be a bad assumption, however, because I
> must be inclusive of all the Scheme primitives as well and I cannot
> control them.

Yes, I suppose a rule must be set that Tcl values cannot be passed to
procedures that will mutate them.

> So, I guess the answer would be no.  The integration can't be
> perfect, but it would be nice if broke in easily recognizable ways.

True.

> 
> > PS, this Tcl stuff is really cool. When it gets reasonably useful and stable,
> > I want to try to make a scwm configuration file in Tcl, that should be something
> > of an acid test of usefulness.
> 
> What I'm concerned about is whether such Tcl would just look like
> Scheme with Tcl syntax.  And, if it is, if that is good enough or if it
> reduces translation to cosmetics.

I imagine a scwm config file written in Tcl would combine the basics operations
of the Tcl language with scwm's window management primitives. In other words,
one would use "proc" instead of "define" to define procedures, and so on. Instead
of writing

(window-style "*" #:fg "red" #:bg "black")

I'd write

window-style "*" -fg "red" -bg "black";

This is, on one level, purely cosmetic. But on another level it is extremely
useful because it allows users to leverage existing language skills, and helps
those who have difficulty with the parentheses. This simple example is pretty
obvious, but I am curious to see how well this will scale to more complex things.

I expect it will work out rather nicely because I have designed many things in
scwm to have a fairly declarative syntax, which should allow for a very natural
Tcl-ish translation.

 - Maciej