[vwnc] Pragmas - Have we misused them?

Eliot Miranda wrote:

[snip]

I don't want to drag this out or jump down people's throats all the time.  Apologies.  I will just say, though, that the tooling costs have proved prohibitive.  Steve and I never got round to implementing first-class inst vars, which were the most important feature we needed.  The parcel, package and source formats change.  The programming GUIs all change.  The change tracking system changes, etc.

Hi Eliot,

Please enlighten me on the wonderfulness of first-class inst vars.

Donald

[ jWarrior ]
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Jul 22, 2008, at 3:42 PM, Donald MacQueen wrote:

The posts I wrote on the ideas around this were:

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=What_is_there_to_a_name&entry=3373674497

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Slots_all_the_Way_Down&entry=3373903413

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Managing_Instance_Variables_Methodically&entry=3376826809

There's actually a couple of "proof of concept" spikes I wanted to do  
with this, to push the boundaries of what you could do with real  
slots. I just haven't ever gotten to the others. They included,  
amongst others I've surely forgotten...

1) Attaching comments to the variable objects. So that when you rename  
instance variables, or remove them, or push them up, or pull them  
down, the comment stays linked to the inst var, instead of encoded in  
some semi-canonized syntax in the class comment, which inevitably  
falls out of sync with reality.

2) Having the Compiler work with the slots to emit store and/or fetch  
byte codes. So that you could define different kinds of Slot types,  
that did more than just basic assign/access, perhaps doing persistance  
like things.

--
Travis Griggs
Objologist
One man's blue plane is another man's pink plane.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 23.07.2008 um 06:52 schrieb Travis Griggs:

> 1) Attaching comments to the variable objects. So that when you rename
> instance variables, or remove them, or push them up, or pull them
> down, the comment stays linked to the inst var, instead of encoded in
> some semi-canonized syntax in the class comment, which inevitably
> falls out of sync with reality.

Apropos. I think it's worth thinking about whether it really makes  
sense to mix up two different worlds of documentation:

        (1) Information needed to understand and extend on the implementation  
and
        (2) API descriptions required for application development.

Commenting on instance variables is clearly implementation focus,  
because from the pov of an application developer, instance vars should  
be entirely opaque. There are two different target audiences. Perhaps  
implementation-specific information should be kept separately.

IMO, to a significant extent, VW already requires developers to  
research and explore the depths of a particular implementation instead  
of just reading and using a documented API (simply because this kind  
of documentation is hard to find and very costly to provide). So I  
would rather like to see better ways for documenting APIs than  
attaching comments to implementation objects.

What about attaching comments to protocols? I often find myself  
wanting to do that.

Just a thought.
Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 23.07.08 00:50 schrieb "Eliot Miranda" unter <[hidden email]>:
> Briefly, there are a lot of things one could do with 1st
> class IVs but the most obvious need right now is to be able to define that a
> parcel/package adds just one inst var to an existing class without having to
> state the class's entire definition.  Stating the entire definition is an
> example of conflict-entailing extensibility because two separate packages
> that want to add inst vars to the same class collide if they have to state
> the entire definition.

That would be nice to have. In most cases, one use a subclass with
additional variables or alter the design, but sometimes that does not work.
It may be a bit difficult to do it right though. There's the problem of
ensuring a consistent order of the instance variables (similar to the
problem of ordering menu entries), and of conflicting variable names defined
in different packages. Given the years it took to eliminate the bugs related
to overrides, I suspect that it will not be easy. One also needs a solution
for code using instVarAt: and its relatives.

Am 23.07.08 06:52 schrieb "Travis Griggs" unter <[hidden email]>:
> 1) Attaching comments to the variable objects. So that when you rename
> instance variables, or remove them, or push them up, or pull them
> down, the comment stays linked to the inst var, instead of encoded in
> some semi-canonized syntax in the class comment, which inevitably
> falls out of sync with reality.

That would be a Good Thing. It would also be consistent with the move from
class variables to shared variables which happened in VW5 (or was it in
VW7?).
 
> 2) Having the Compiler work with the slots to emit store and/or fetch
> byte codes. So that you could define different kinds of Slot types,
> that did more than just basic assign/access, perhaps doing persistance
> like things.

+1

Two examples from projects I have worked on:

- In JNIPort, there are Wrapper classes for Java classes. One can implement
them explicitly instead of letting JNIPort generate them at runtime, such
that one can extend the Java class by custom Smalltalk methods. For those
classes, it would be handy to declare that some instance variables represent
fields in the corresponding Java class. Those would not be instance
variables in the current sense, as they would read to and write from a field
in a Java object.

- In a project at the Swiss National Bank, we needed histories of attribute
values. E.g., the address of a company usually changes over time (New York
from 1980 to 1990, Boston from 1991 to 2005 etc.). I have experimented with
modified ClassBuilders and class definition methods where I could declare
instance variables as histories (this didn't make it into productive code, I
did it after the project). These variables contained histories of values,
and had special accessor methods which had additional Timestamp parameters.
E.g., reading a value would be something like

    aCompany addressAt: aTimestamp

Setting a value would be similar to this:

    aCompany address: anAddress from: aTimestamp to: aTimestamp

The accessor methods were generated when the class definition was accepted.

The second case can't be solved by having the Compiler emit different byte
codes, because one needs more than one setter and getter method. Of course,
the "normal" accessors could answer the value history itself, but I would
prefer using more intention revealing selectors (#myInstVarHistory). I am
also not sure if I would want a setter method in this case.

Another use case might be maintaining change logs of variable values (but
probably Tim Howard's MutableDomainObjects are better suited for this
purpose).

So yes, Slots instead of instance variables would be a good idea.

Joachim Geidel


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

At 04:00 PM 7/23/2008, Andre Schnoor wrote:
>IMO, to a significant extent, VW already requires developers to
>research and explore the depths of a particular implementation instead
>of just reading and using a documented API (simply because this kind
>of documentation is hard to find and very costly to provide). So I
>would rather like to see better ways for documenting APIs than
>attaching comments to implementation objects.

This would receive my vote as well.

To clarify one point, though: I don't agree that it's "very costly"
to provide such APIs. Many other language communities provide them,
and documented APIs are widely considered good industry practice. It
seems, rather, that the Smalltalk community believes that we don't
have to observe such practices, due to questionable claims about
so-called intention-revealing selectors, or linguistic exceptionalism.

>What about attaching comments to protocols? I often find myself
>wanting to do that.

Wouldn't method signatures be the appropriate place?

M

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc