tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] dict

[Joe E. <jen...@fl...>]

Martin Lemburg wrote:
>
> I was surprised, that introducing dicts nobody seemed to think about traces o
> n dicts and their elements/keys.
>
> Is it true, that this is the first time, that "traces" on dicts are discussed
>  in this list?

No.  The absence of traces on dict elements is one of
the principal things that distinguishes dicts from arrays.


--Joe English

  jen...@fl...

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Robert H. <si...@gm...>]

Kristoffer Lawson wrote:
> On 27 Oct 2006, at 02:57, Robert Hicks wrote:
> 
>> I would have to see some code for a prototypical system to judge its
>> Tcl'ness.
> 
> Try looking at the documentation at
> 
> http://people.fishpool.fi/~setok/proj/Selfish/
> 
> and also downloading the package. There should be some brief examples  
> there which may or may not be illustrative. I'm not claiming them to  
> be particularly good examples, but perhaps it will give you some idea.
> 
>             /  http://www.fishpool.com/~setok/
> 
> 

So are you going anywhere with Selfish or what it just a "proof of concept"?

Robert

Re: [TCLCORE] dict

[Martin L. <mar...@gm...>]

Hi Neil,

I was surprised, that introducing dicts nobody seemed to think about traces on dicts and their elements/keys.

Is it true, that this is the first time, that "traces" on dicts are discussed in this list?

For me it was clear, haven't thought about its existence, that a trace on a dict behaves like a trace on an array.

But ... looking at the man pages ... there is no token "dict" in the list of possible trace states - read, write, unset, array. I complete overlooked, that dicts are not that integrated in tcl like the "old" primary types "scalars" and arrays.

So - do we have to write a TIP to define the traces on dicts to ensure that their are treated like their pendents?

----

Back to the direct access to list, dict and array elements.

There was no comment about the suggestion to allow the following:

    % set data {4 c 3 a 2 b}
    4 c 3 a 2 b
    % set data<0>; # list element access
    4
    % set data(4); # dict access
    c
    % array set dataArr $data
    % set dataArr(4); # array access
    c

The "<" and ">" characters are currently not usable in variable names. Ok - putting a variable name in braces allows to use "<" and ">".

What's about introducing the scheme varName<numericalIndex> as direct list access?

Ok - if somebody writes today ...

    % set foo 3
    3
    % set faa 4
    4
    % expr {$foo<$faa}
    1

... than the parser must not tell, that it is missing the closing ">".
And if 

Perhabs not that nice. :(

And what's about treating dicts equally to arrays in their element access?

Best regards,

Martin

-------- Original-Nachricht --------
Datum: Thu, 26 Oct 2006 15:57:48 +0100
Von: Neil Madden <ne...@cs...>
An: Kristoffer Lawson <se...@fi...>
Betreff: Re: [TCLCORE] dict

> 
> On 26 Oct 2006, at 14:51, Kristoffer Lawson wrote:
> 
> > On Thu, 26 Oct 2006, Neil Madden wrote:
> >
> >> set foo {a 1 b 2}
> >> .e configure -textvariable foo(a)
> >>
> >> It works for arrays, but is meaningless for dicts or lists as their
> >> elements are not variables (and do not change).
> >
> > But foo is a variable. Why would it not, invisibly, look up foo
> > and treat the contents as a dict to get the 'a' key from that. If a
> > variable is treated as an array, let it be an array.
> 
> OK, I can kind of see a scheme where this might work. Instead of  
> storing traces directly with array elements, you instead store the  
> trace with the containing variable along with a path for what element  
> to report changes for. There are lots of details though, e.g. what  
> happens in the case:
> 
> set foo {a 1 b 2}
> .e configure -textvariable foo(a)
> set foo {b 2)
> 
> Now "a" has disappeared entirely -- do we fire an unset trace on that  
> element? Do we delete the trace? Do we fire a write trace for foo(b)  
> too, even though it hasn't actually changed?
> 
> Now, how about after the first two lines above we do:
> 
> dict set foo a 1
> 
> We've set "a" to the same value as it was before. Do we fire a write  
> trace? If so, what about the further example:
> 
> set foo [dict replace $foo a 2]
> 
> Do we fire write traces on every element? Or just those that have  
> changed?
> 
> -- Neil
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[<Mic...@fr...>]

> This is reversal from XoTcl, which had "proc" and "instproc".
> "proc" is like "self.method"--it always defines a subcommand of
> the object it's called on, whether that object is a normal object
> or a class.  When called on a class, "instproc" defines a subcommand
> of the class's instances.  We turned it around, reasoning that
> you're usually going to want to define subcommands of instances;
> adding subcommands to classes is less usual.
> 
> As usual, it's all about commensurate effort--the usual thing
> should be simple, and less usual things should be possible.

Well, if that's your goal then this is almost too obvious to say out loud, 
but why not just reverse them then--ie:

proc            => classproc (or classmethod)
instproc    => proc (or method)

and, of course, this works for "filter" and everything else.

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Robert H. <si...@gm...>]

Kristoffer Lawson wrote:
> On 27 Oct 2006, at 03:04, Robert Hicks wrote:
> 
>> Kristoffer Lawson wrote:
>>> On 26 Oct 2006, at 23:57, Donal K. Fellows wrote:
>>>
>>> I need to find the paper describing a class-based system (Smalltalk
>>> really), but remember that Self-like OO systems have inheritance
>>> between any objects, as well as cloning.
>>>
>> Java is a "class-based" system but Smalltalk is not. Smalltalk is an
>> "object-based" system.
> 
> Hm, well that would definitely depend on your definition as Smalltalk  
> has classes which act as templates and instances of these classes.  
> Sure, everything in Smalltalk is also an object, just as classes in  
> XOTcl are also objects. To some extent they are in Java, although  
> frustratingly ambiguous at times.

Yeah, I think Java is firmly in the "class-based" because that is its 
central paradigm and not everything in Java is an object. In 
differentiating the two in Smalltalk (while it has classes) everything 
is an object and that is how you think (i.e. passing messages between 
objects). Although there are a variety of "tags" to check when looking 
at what kind of object system a language has. Too many to list here! :)

It does depend on definition though...I have just never heard Smalltalk 
called a "class-based" system. Although it could be according to what 
your definition is (as you said).

Robert

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Will D. <wi...@wj...>]

Gerald,

Snit 2.0 (2.1, as of the latest Tcllib release) is a version of Snit
that depends on features of Tcl 8.5, not including 257.  So, for  
example,
it uses [namespace ensemble] for method dispatch.

See the Snit FAQ in the Tcllib documentation for more details. :-)

Will


On Oct 27, 2006, at 5:51 AM, Gerald W. Lester wrote:

> Will Duquette wrote:
>> On Oct 26, 2006, at 4:57 PM, Robert Hicks wrote:
>>> I personally find Snit to be a more natural Tcl OO system. I am  
>>> sure different mentalities gravitate towards different types of  
>>> OO as is evident with all the different types of OO out there. I  
>>> have not heard anyone say anything bad about Snit at all (except  
>>> its speed which is being addressed).
>> Snit isn't perfect; speed is an issue, especially speed of object  
>> creation, and the stack traces it produces are extremely ugly; and  
>> although delegation is really cool there are times when true  
>> inheritance would be really useful. On the other hand, I've done  
>> some method dispatch benchmarks between the current 257  
>> implementation and Snit 2.1 (which is based on [namespace  
>> ensemble]) and so far as I can tell they perform about the same  
>> here. I'm rather surprised, and pleased. Of course, 257 can  
>> probably be optimized further.... :-)
> What is the difference between 257 and Snit 2.0?
> -- +-------------------------------- 
> +---------------------------------------+ | Gerald W. Lester |  
> |"The man who fights for his ideals is the man who is alive." -  
> Cervantes|  
> +--------------------------------------------------------------------- 
> ---+
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642______________________________ 
> _________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] oo-oh ... not ready for 8.5

[Will D. <wi...@wj...>]

On Oct 27, 2006, at 3:10 AM, Kristoffer Lawson wrote:

>
> On 27 Oct 2006, at 12:23, Donal K. Fellows wrote:
>
>> But the fact that I was able to conceive of a new kind of relation
>> indicates to me that the set of relations identified in the TIP may
>> not
>> be the set that Tcler's really want. I look forward to seeing other
>> people's ideas here.
>
> For what it's worth, I agree with you that general delegation would
> be a good relation to add. Naturally many things can be done with
> filters, but that's not really the point (otherwise we could have
> only filters and nothing else). Besides, in the XOTcl world, if a
> method does not exist I believe you get an error no matter what
> filters are set. Thus the correct place for that kind of build-it-
> yourself delegation would be the unknown handler, which brings us to
> the next comment.. (and no, I'm not sure if 279 is meant to work in
> the same way)

Regarding delegation: Snit is set up to *primarily* allow
delegation to other objects; but in fact there's a powerful
mechanism to delegate to anything you like.  Plus, it's
all tied in with Snit's support for hierarchical methods,
which is a significant convenience.

I can build Snit's delegation on top of 257's "forward".  It'd be
nice to have a more powerful mechanism to draw on--but I don't want
such a mechanism to be so focussed as to solve 50% of my problem
perfectly and make the other 50% so difficult that I have to do
98% of the work in my code anyway.

Will

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Will D. <wi...@wj...>]

On Oct 27, 2006, at 1:45 AM, Donal K. Fellows wrote:

> Gustaf Neumann wrote:
>> this explains, why you don't like the name for snit, but this does  
>> not
>> have to be necessarily the same in snit as in ::oo.
>>
>> In tip257 there is as well a conceptual gap: a "method" appears as  
>> a new
>> new thing, neither proc nor command, not part of any namespace  
>> (can't be
>> exported/imported, although the object has a namespace). From the
>> discussion, i see no interest in converging these concepts in  
>> tip257. From
>> a language desing, this would be desirable.
>>
>> I think, Neil was referring to the conceptual similarities between an
>> object (as in xotcl) and an ensemble, which are lost in current 257.
>>
>> Does the oo core language really need object specific procs?
>
> This is an important point.

(Donal goes on to explain why methods aren't simply procs in namespaces
in 257.)

Now, given that methods aren't procs, why might we want
object- or class-specific procs?  What I mean by this is procs
that are defined in the class or object namespace and are callable
as bare commands within those namespaces?  Because they are faster!

I frequently find that my code would be cleaner if I write some small
helper proc.  If I can write that helper proc as a proc rather than
as a method--that is, if it's really a function, with no side effects
or need to access object state--then making it a proc gives me a
slight performance gain with no loss of clarity.

On top of that, Snit supports procs of this kind--and I'm trying
to figure out how to build Snit on top of 257.  If it can't be
done, that would be a problem.

Will

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] dict changes

[<Lar...@re...>]

2006-10-27 kl. 14.17 skrev <ju...@pr...>:
>
> *I propose changing all the dict subcommands to take keys grouped as=20=

> Tcl lists instead of as a seqence of an unknown number of separate=20
> arguments*
>
> we can then perform the above incr:
>
> dict incr tclcore {tipx present} 2

A problem with this, from a usability point of view, becomes clear when=20=

you start considering non-constant keys (this is most likely the main=20
case; nested dicts with constant keys only are just fancy=20
pseudo-structs). It's certainly still easy to build the necessary list=20=

of keys using [list], but it is longer and obscures what is going on.=20
In those cases where I've written procs that took some sequence of=20
values as a list that was always being constructed on the fly like=20
this, the results weren't appealing. Ungrouped arguments tend to work=20
better.

If there is anything that worries me about [dict], it is probably=20
rather how to deal with nestings where dicts and lists are mixed. I'm=20
currently considering a data structure design where there might be=20
lists of dicts, the values of which are again lists, and whose elements=20=

I'd like to access quickly (both get and set). Turning all the lists=20
into dicts is not a solution in this case (amongst other things because=20=

the string representations of dicts are not canonical with respect to=20
string equality). A [dict lset] would help, but can not completely do=20
away with the need to unpack data.

OTOH, I have some code (originally written for Tcl 7!) where I work=20
with nested dictionaries (constantly unpacking using [array set],=20
packing using [array get]), and it works perfectly well throughout. I=20
suspect the need for and overhead in nesting depends a lot on whether=20
one is able to match the lists and dicts to natural data units on which=20=

there are natural operations. E.g., in your example it is a bit=20
artificial that the "increment yes count" operation should act on a=20
dictionary of vote results; having it operate on a single vote result=20
is more natural. A more natural example is probably

  proc register_datum {dictvar value} { ... }

where the dictvar value is something like

  count 10 sum 15 squaresum 25 valuecounts {1 5 2 5}

In your syntax, the natural way of incrementing the valuecounts entry=20
for a value would be something like

  upvar 1 $dictvar D
  dict incr D [list valuecounts $value]

whreas current [dict] requires

  upvar 1 $dictvar D
  dict update D valuecounts D2 {dict incr D2 $value}

but when there is also a need to update the count, sum, and squaresum=20
entries of D, then [dict update] doesn't look all that bad anymore:

  dict update D valuecounts D2 count count sum sum squaresum squaresum {
     dict incr D2 $value
     incr count
     set sum [expr {$sum+$value}]
     set squaresum [expr {$squaresum + $value*$value}]
  }

Lars Hellstr=F6m=

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Gerald W. L. <Ger...@co...>]

Will Duquette wrote:
> On Oct 26, 2006, at 4:57 PM, Robert Hicks wrote:
>
>   
>> I personally find Snit to be a more natural Tcl OO system. I am sure
>> different mentalities gravitate towards different types of OO as is
>> evident with all the different types of OO out there. I have not heard
>> anyone say anything bad about Snit at all (except its speed which is
>> being addressed).
>>     
>
> Snit isn't perfect; speed is an issue, especially speed of
> object creation, and the stack traces it produces are
> extremely ugly; and although delegation is really cool there
> are times when true inheritance would be really useful.
>
> On the other hand, I've done some method dispatch benchmarks between
> the current 257 implementation and Snit 2.1 (which is based on
> [namespace ensemble]) and so far as I can tell they perform
> about the same here.  I'm rather surprised, and pleased.  Of course,
> 257 can probably be optimized further.... :-)
>   
What is the difference between 257 and Snit 2.0?

-- 
+--------------------------------+---------------------------------------+
| Gerald W. Lester                                                       |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

Re: [TCLCORE] oo-oh ... not ready for 8.5

[<Lar...@re...>]

2006-10-27 kl. 00.30 skrev Donal K. Fellows:
>
> I (reluctantly) agree to not
> push for any OO system in 8.5 on the proviso that we stick to that=20
> short
> cycle for 8.6 (I hate committing to 8.6, but we need a version out =
with
> an OO system so that it can get extensive in-field testing before 9.0
> when it would be nice to see how much of Tk can be founded on =
objects.)

It occurs to me that this "8.5 will be the last 8.x, then it's 9.0 all=20=

the way" additude may be the culprit on which most of the blame for the=20=

4 years (and counting?) release cycle of 8.5 should be placed. If=20
something is going to be the last in its kind -- the zenit of=20
technological ingenuity -- then it is hard to let go of it, because=20
there is always some more polishing to do and features to stick in.=20
OTOH, as long as there will be a new model next year, then some of the=20=

goodies can get to wait for that.

There have been plans for what should be in various releases along the=20=

way (I vaguely recall something about 8.5 should be all about improving=20=

Tk), but it's my impression that the TIPs actually submitted didn't=20
match those expectations; there turned out to be a lot that could be=20
improved in Tcl as well. There probably still is (although 8.5 now=20
meets an anstonishingly large amount of the things that have been on my=20=

wish list).

At the current rate of ingenuity coming in, I wouldn't be totally=20
surprised if there gets to be an 8.7 as well. In that case, it would=20
probably be a good idea to not wait until 2010 to accept the notion,=20
and instead let it come naturally if/when it comes.

Lars Hellstr=F6m=

[TCLCORE] dict changes

[<ju...@pr...>]

HelOO oo-weary(?) TclCorers,

This is an appeal for changes to the dict subcommands.

It has nothing to do with radical changes to allow dict access via =
arraylike syntax or anything like that - just modest but important =
changes to the way dict subcommand arguments are currently specified.

My earlier 'dict is under the radar' comments were not meant to imply =
that the command hasn't been 'out there' and promoted - actually I think =
it's just the nature of the animal that it takes a while to be adopted.

I suspect that *initially* most people will use dict in basic un-nested =
form - but once they are more comfortable with it and inevitably start =
trying to use it as a nested datastructure - they will discover as I =
have that the dict subcommand interface has frustrating shortcomings.

It can take a long time to get comfortable with a new command and start =
trying to use it to it's full potential.
Right now dict is hamstrung by it's interface - and now is the time to =
fix it.

I can understand any consternation and surprise people may have that =
this issue would be raised about dict so late in the umm.. 'release =
cycle'.
------

The dict interface as it stands requires it's 'key' arguments to be =
presented consecutively on the commandline as opposed to grouped in a =
Tcl list.

Take an example dict value that exhibits *simple* 1st level nesting:=20

{tipx {champions 2 naysayers 2  present 100} tipy {naysayers 4 champions =
3 present 200}}


the existing [dict set] & [dict get] can operate directly at the level =
of the subdicts

%dict get $tclcore tipx naysaysers
2

%dict set tclcore tipx issues {a b c}
{tipx {issues {a b c} present 100 champions 4 naysayers 2} tipy =
{naysayers 4 champions 3 present 200}

however...

[dict incr] can only operate at the level of the outer dictionary.

%dict incr tclcore tipx present 2
expected integer but got "issues {a b c} presnet 100 champions 4 =
naysaysers 2"

This is naturally a  consequence of using separate key arguments to =
access nested dict elements.
You simply don't have the flexibility to provide needed additional =
arguments (in this case the optional 'increment' value to incr); because =
you have no separation between 'keys' and the other arguments.

The list of subcommands that fail to operate directly at nested levels =
in dicts because of this, includes:
[dict append]
[dict incr]
[dict keys]
[dict lappend]
[dict replace]
[dict values]

This is in contrast to other subcommands that can currently operate at =
nested levels:
[dict set]
[dict unset]
[dict get]
[dict exists]
[dict remove]

( There are yet other commands that could theoretically operate at any =
nest level but don't..
[dict size]
[dict info]
I don't see why they couldn't be extended.. but that's an argument for =
another time. )


We are left in a situation where to perform the incr above, you need to =
jump through strange hoops as mentioned in my previous tclcore message =
regarding dicts.
i.e  extract/update/repack etc.


They could however ALL operate at any level of nested dicts easily and =
consistently.


*I propose changing all the dict subcommands to take keys grouped as Tcl =
lists instead of as a seqence of an unknown number of separate =
arguments*

we can then perform the above incr:

dict incr tclcore {tipx present} 2


*much of the code currently written to use dicts - will not change if it =
is not using nested dicts!*


i.e the following is legal under both the existing and proposed systems, =
as 'tipz' can of course be considered a Tcl list of length 1:
dict set tclcore tipz {champions 0}

---

A synopsis of the change:

CURRENT:
dict <subcommand> <dictionaryValue> key ?key ...?

PROPOSED:
dict <subcommand> <dictionaryValue> {key ?key ...?}
i.e
dict <subcommand> <dictionaryValue> $keylist
i.e
dict <subcommand> <dictionaryValue> [list key ?key ...?]

----
some specific examples:

dict append dictionaryVariable key ?string ...?
=3D>
dict append dictionaryVariable keylist ?string ...?


dict set dictionaryVariable key ?key ...? value
=3D>
dict set dictionaryVariable keylist value


---
Possible future enhancements.

Placing a bound on the currently free key arguments would allow certain =
dict subcommands to be extended in interesting ways.

e.g
[dict get] could return multiple entries in one call:

%lassign [dict get $tclcore {tipx champions} {tipy champions}] champx =
champy


[dict with] could accept an 'arrayname' argument to collect keys and =
values instead of the current behaviour
which creates variables in the calling context.


e.g
%dict with tclcore tipx VAR {parray VAR}
VAR(champions) =3D 2
VAR(naysayers) =3D 2
VAR(present)   =3D 100

---
some downsides:
[dict keys] & [dict values] are currently specified as:
dict keys|values dictionaryValue ?globPattern?

proposed enhancement:
dict keys|values dictionaryValue keylist ?globPattern?

While the proposed syntax allows direct retrievals of keys/values at any =
level, it is a little more clumsy for the common base case:
e.g -  supply an empty list to represent the outer dictionary:
%dict keys tclcore {} *
tipx tipy tipz

This could be simplified with some careful DWIMmery to support the case =
where no glob pattern is supplied
e.g
%dict keys tclcore
tipx tipy tipz

Some people may also consider:
%dict get $tclcore {tipx naysayers}
to be less beautiful than the current
%dict get $tclcore tipx naysayers



I believe this slight clumsiness is immaterial, and well worth it in =
terms of the improved consistency & learnability of the proposed syntax.
Also containing the keys in lists vastly improves the flexibility for =
adding arguments to existing or yet-unthought-of subcommands.=20


---
Note specifically - [dict with] as it stands is seriously flawed with =
respect to dumping variables in the calling context. The above proposal =
would allow [dict with] to be modified to fix this by accepting an =
arrayname, but in the event that the proposal is rejected=20

- I would seriously argue for the removal of [dict with].

It is a recipe for code that appears to work at first but fails when =
called with a dict that happens to have keys that collide with =
variables.
I hope I'm not being too rude when I say that 'hideous misfeature' are =
the words that spring to mind :)
---

Now.. why am I not TIPing this?
A: I've never TIPped before, and while it's a 'simple' interface change, =
I would never dare say the underlying code changes will be at all simple =
and unfortunately I'm not proficient enough to make changes at the C =
level.
I fear this may seem like a 'make work' issue for an already overloaded =
DKF :(

I can only offer my Tcl wrapper for people to try out the effects of the =
changes themselves at: http://wiki.tcl.tk/dictn  and also, I could help =
by updating documentation or trying to rephrase some of this into a =
format suitable for a TIP if someone will be kind enough to guide me.

I don't think a Tcl wrapper however is a suitable solution for a major =
Tcl datastructure such as this.


p.s  I love dict.. no really.. It's almost great :)


Julian

Re: [TCLCORE] oo-oh ... not ready for 8.5

[Kristoffer L. <se...@fi...>]

On 27 Oct 2006, at 12:23, Donal K. Fellows wrote:

> But the fact that I was able to conceive of a new kind of relation
> indicates to me that the set of relations identified in the TIP may  
> not
> be the set that Tcler's really want. I look forward to seeing other
> people's ideas here.

For what it's worth, I agree with you that general delegation would  
be a good relation to add. Naturally many things can be done with  
filters, but that's not really the point (otherwise we could have  
only filters and nothing else). Besides, in the XOTcl world, if a  
method does not exist I believe you get an error no matter what  
filters are set. Thus the correct place for that kind of build-it- 
yourself delegation would be the unknown handler, which brings us to  
the next comment.. (and no, I'm not sure if 279 is meant to work in  
the same way)

> should not forget to analyse #279 for itself. (BTW, there's no details
> at all in the TIP of how unknown method names are responded to in
> dispatch, which makes the delegation trick you're using invalid  
> from the
> formal context of the TIP. You ought to plug that specification hole.)

Exactly. I was wondering about 'unknown' myself.

There are a few open areas in the TIP. Nothing that can't be plugged  
by any means.

            /  http://www.fishpool.com/~setok/

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Kristoffer L. <se...@fi...>]

On 27 Oct 2006, at 03:04, Robert Hicks wrote:

> Kristoffer Lawson wrote:
>> On 26 Oct 2006, at 23:57, Donal K. Fellows wrote:
>>
>> I need to find the paper describing a class-based system (Smalltalk
>> really), but remember that Self-like OO systems have inheritance
>> between any objects, as well as cloning.
>>
>
> Java is a "class-based" system but Smalltalk is not. Smalltalk is an
> "object-based" system.

Hm, well that would definitely depend on your definition as Smalltalk  
has classes which act as templates and instances of these classes.  
Sure, everything in Smalltalk is also an object, just as classes in  
XOTcl are also objects. To some extent they are in Java, although  
frustratingly ambiguous at times.

            /  http://www.fishpool.com/~setok/

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Kristoffer L. <se...@fi...>]

On 27 Oct 2006, at 02:57, Robert Hicks wrote:

> I would have to see some code for a prototypical system to judge its
> Tcl'ness.

Try looking at the documentation at

http://people.fishpool.fi/~setok/proj/Selfish/

and also downloading the package. There should be some brief examples  
there which may or may not be illustrative. I'm not claiming them to  
be particularly good examples, but perhaps it will give you some idea.

            /  http://www.fishpool.com/~setok/

Re: [TCLCORE] oo-oh ... not ready for 8.5

[Donal K. F. <don...@ma...>]

Gustaf Neumann wrote:
> there is no need to define a delegate relation. tip#279 supports 
> exactly this delegaton through a language primitive on the per-object 
> and per-class level. For SNIT-like wild-cards, one can use te 
> approaches in http://wiki.tcl.tk/11033 or filter based approaches. 
> Certainly, the language in the tip#279 can delegate to every tcl
> command.

That feels like you're thinking "how can avoid taking up this new idea
by doing a hack" to me. :-)

OK, I'm being _very_ unfair here. I was just trying to think what sorts
of relations might be "missing". The other ones from classic OO analysis
are 'generalizes' and 'aggregates' but I don't know if they're useful
here. Suspect not though; generalization is a solution for a problem
that Tcl scripts blithely ignore anyway, and aggregation is more of an
organizational feature and not something that drives method dispatch.

But the fact that I was able to conceive of a new kind of relation
indicates to me that the set of relations identified in the TIP may not
be the set that Tcler's really want. I look forward to seeing other
people's ideas here.

> Has tip#257 any own solutions for delegation?

No more than XOTcl has to tell the truth. I only thought of this two
days ago. :-D (Yes, I didn't blurt the idea out immediately.) But we
should not forget to analyse #279 for itself. (BTW, there's no details
at all in the TIP of how unknown method names are responded to in
dispatch, which makes the delegation trick you're using invalid from the
formal context of the TIP. You ought to plug that specification hole.)

Donal.

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Gustaf N. <ne...@wu...>]

Donal K. Fellows schrieb:
> Gustaf Neumann wrote:
>> this explains, why you don't like the name for snit, but this does 
>> not have to be necessarily the same in snit as in ::oo.
>>
>> In tip257 there is as well a conceptual gap: a "method" appears as a 
>> new new thing, neither proc nor command, not part of any namespace 
>> (can't be exported/imported, although the object has a namespace). 
>> From the discussion, i see no interest in converging these concepts 
>> in tip257. From
>> a language desing, this would be desirable.
>>
>> I think, Neil was referring to the conceptual similarities between an 
>> object (as in xotcl) and an ensemble, which are lost in current 257.
>>
>> Does the oo core language really need object specific procs?
>
> This is an important point.
...

>  Coupled with a little bit of
> call-frame hacking, this has allowed me to make method invokation,
> especially of deep and complex inheritance hierarchies, very fast and
> easy to use. In particular, people writing methods can treat them just
> like normal procedure calls, and do not need to do anything with [self
> callinglevel] to see the caller.
there are multiple ways implemention this in the c-layer, one
has different means being an extension or in the core. On the
C level in most cases, one ends up putting the calling object
(i guess, this was what you were refering to) on the stack,
as extra argument or internally.

However, you are talking here about your implementation in C,
but not adressing the main focus of the message,  the conceptual
conceptual differences for applications using this from the tcl-layer.
While most users don't care about the C implementation, they
care about conceptual simplicity and orthogonality.  New
now concepts with different properties reduce this.

-gustaf neumann

Re: [TCLCORE] [oo::define] and self.*

[Donal K. F. <don...@ma...>]

Michael Kirkham wrote:
> Ok, so..
> 
> oo::class <name> {}  ;# Defines an empty class named <name>
> oo::class <name>     ;# Returns the class-object of object <name>
> oo::method [oo::class SomeObj] ...

Actually, as things stand the first two will (probably - depends on
whether things have been reconfigured by you) complain that <name> is an
unknown method name, and that you should have used 'create' or
'destroy'. :-) I did have some code at one point that did the magical
creation stuff, but it was unpopular DWIMmery that got dropped. You
could script it in if you wanted, of course; it'd just take an unknown
method handler.

[...looks again at the example...]

Oh, you're expecting to pass about typed values, and you're assuming
that the class is going to be distinguishable from the object? Yuck. I
do not believe that that's Tcl-ish. We're not VB.NET you know!

Donal.

Re: [TCLCORE] [oo::define] and self.*

[Michael K. <mi...@mu...>]

On Fri, 27 Oct 2006, Michael Kirkham wrote:

> Ok, so..
>
> oo::class <name> {}  ;# Defines an empty class named <name>
> oo::class <name>     ;# Returns the class-object of object <name>
>
> oo::method [oo::class SomeObj] ...

Probably I should shut up because I've not read the TIPs.. but then I'm 
also not sure why the primary command is the oo::whatever and not the 
object/class itself..

$object method ...
as opposed to

oo::method $object ..

or

oo::class method $object ...

or whatever.

The "$object method" form would theoretically allow one to redefine what 
defining a method is for a particular class/object.  Then you could do..

[oo::class $object] method ...

or

[oo::self $something] method ...

or whatever makes sense for what you're talking about.  I'll shut up now 
because I don't really know the details, just complaining about verbosity. 
:)

--
Michael Kirkham
www.muonics.com

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Donal K. F. <don...@ma...>]

Gustaf Neumann wrote:
> this explains, why you don't like the name for snit, but this does not 
> have to be necessarily the same in snit as in ::oo.
> 
> In tip257 there is as well a conceptual gap: a "method" appears as a new 
> new thing, neither proc nor command, not part of any namespace (can't be 
> exported/imported, although the object has a namespace). From the 
> discussion, i see no interest in converging these concepts in tip257. From
> a language desing, this would be desirable.
> 
> I think, Neil was referring to the conceptual similarities between an 
> object (as in xotcl) and an ensemble, which are lost in current 257.
> 
> Does the oo core language really need object specific procs?

This is an important point.

While I started out with a goal of implementing methods using normal
commands, I eventually decided to not do this on the grounds that the
natural C API signature for a method was not the same as the natural C
API signature for a command. Instead, methods take an extra parameter
that specifies the object invokation context (that contains the sort of
thing you'd find out with [self]). The alternatives are to push an extra
stack frame to hold it (which is visible to [upvar] and [uplevel], and
slows down method invokation quite a bit), place the data in the
interpreter (maybe you can make the recursive case or the case with
[upvar]/[uplevel] work right here, but I don't want to have to try to
figure it out!) or to stash it in an extra hidden argument (this is what
I tried first, actually, but it's ugly). Coupled with a little bit of
call-frame hacking, this has allowed me to make method invokation,
especially of deep and complex inheritance hierarchies, very fast and
easy to use. In particular, people writing methods can treat them just
like normal procedure calls, and do not need to do anything with [self
callinglevel] to see the caller.

In short, introducing the new "method" stuff make life easier. It makes
the code cleaner, and it makes the _use_ of the code cleaner too; it's
the second part that makes it really worthwhile. It also makes method
invokation faster, which isn't a bad thing. :-)

Donal.

Re: [TCLCORE] [oo::define] and self.*

[Michael K. <mi...@mu...>]

On Fri, 27 Oct 2006, Donal K. Fellows wrote:

> Date: Fri, 27 Oct 2006 09:15:20 +0100
> From: Donal K. Fellows <don...@ma...>
> To: Michael Kirkham <mi...@mu...>
> Cc: Tcl Core List <tcl...@li...>
> Subject: Re: [TCLCORE] [oo::define] and self.*
> 
> Michael Kirkham wrote:
>> Let oo::method figure out if it's a class or object.  Let oo::class just 
>> define classes and oo::object just define objects.  etc.
>
> That would work (and be nice too) except that classes are kinds of
> objects, and sometimes you want to manipulate them as such. This means
> that when you've got a class you've got an ambiguous case. The "self."
> prefix is disambiguating precisely this.

Ok, so..

oo::class <name> {}  ;# Defines an empty class named <name>
oo::class <name>     ;# Returns the class-object of object <name>

oo::method [oo::class SomeObj] ...

--
Michael Kirkham
www.muonics.com

Re: [TCLCORE] [oo::define] and self.*

[Donal K. F. <don...@ma...>]

Michael Kirkham wrote:
> Let oo::method figure out if it's a class or object.  Let oo::class just 
> define classes and oo::object just define objects.  etc.

That would work (and be nice too) except that classes are kinds of
objects, and sometimes you want to manipulate them as such. This means
that when you've got a class you've got an ambiguous case. The "self."
prefix is disambiguating precisely this.

Donal.

Re: [TCLCORE] [oo::define] and self.*

[Michael K. <mi...@mu...>]

On Thu, 26 Oct 2006, Neil Madden wrote:

> On 26 Oct 2006, at 16:48, Donald G Porter wrote:
> ...
>>
>> Seems to my uneducated perspective it would be clearer to have two
>> defining commands:
>>
>>   oo::objdef $object $script1
>>
>>   oo::classdef $class $script2
>
> Or even just make these sub-commands of oo::object and oo::class:
>
> oo::class define $class {
>     method ...
> }
> oo::object define $object {
>     method ...
> }
> and
> oo::class method $class ...
> oo::object method $object ...
> etc

Call me crazy, and I haven't more than glanced at the TIPs, but why try to 
stuff everything in "define"?

oo::method <classOrObject> <name> <args> <body>

etc.

Let oo::method figure out if it's a class or object.  Let oo::class just 
define classes and oo::object just define objects.  etc.

It's not like this it is polluting the global namespace to have separate 
commands for things, and it looks really weird to be mixing namespace 
qualifiers and ensemble style calls in one command, not mention being very 
verbose.

--
Michael Kirkham
www.muonics.com

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Will D. <wi...@wj...>]

On Oct 26, 2006, at 4:57 PM, Robert Hicks wrote:

> I personally find Snit to be a more natural Tcl OO system. I am sure
> different mentalities gravitate towards different types of OO as is
> evident with all the different types of OO out there. I have not heard
> anyone say anything bad about Snit at all (except its speed which is
> being addressed).

Snit isn't perfect; speed is an issue, especially speed of
object creation, and the stack traces it produces are
extremely ugly; and although delegation is really cool there
are times when true inheritance would be really useful.

On the other hand, I've done some method dispatch benchmarks between
the current 257 implementation and Snit 2.1 (which is based on
[namespace ensemble]) and so far as I can tell they perform
about the same here.  I'm rather surprised, and pleased.  Of course,
257 can probably be optimized further.... :-)

Will

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] [my variable] argument format

[Will D. <wi...@wj...>]

On Oct 26, 2006, at 11:39 AM, Donald G Porter wrote:

> % object create o
> ::o
> % define o method foo {} {my variable \{}
> % o foo
> unmatched open brace in list
>
> [my variable] needs each argument to be a valid list.  TIP language
> suggests it can be any varName.  Should revise the proposal on that  
> point.

Or, is this a bug in the code?  If normal variable names don't
have this contraint, instance variables shouldn't either.

Will

>
> -- 
> | Don Porter          Mathematical and Computational Sciences  
> Division |
> | don...@ni...             Information Technology  
> Laboratory |
> | http://math.nist.gov/~DPorter/                                   
> NIST |
> | 
> ______________________________________________________________________ 
> |
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills