Weblog Page

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Sun, 19 Mar 2006 07:30:39 -0700

xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/19/2006 06:53:50 AM:

>
> One general observation about our discussion: it is often not clear,
> what "namespace"
> refers to, a "tcl namespace" or some kind of an abstract namespace.

I've been guilty of this. I wondered what would happen if XOTcl's objects used their own
concept/implementation of an abstract namespace (or scope) instead of using Tcl namespaces.

(The answer seems to be that it would be a lot of work and it would break XOTcl...)

That said, I think it would be good if, in general, non-XOTcl accesses to an XOTcl object's
attributes didn't assume the way Tcl's namespaces are used, but instead there were object methods
that would construct appropriately qualified names for an instance's attributes.

> i for my part would be happy to have a lower level
> interface to these
> functionalities, having e.g. the management for cmds different from the
> management
> of the vars, but this would be a deeper change in the tcl-internals,
> requireing many
> interface changes.

Does Tip #257 provide a opening for having that discussion with the Tcl Core Team? If there's
willingness to add OO support to Tcl, does that also imply a willingness to at least consider
extending the C API to better support it as well?

      Scott

From: Neil Madden <nem_at_cs.nott.ac.uk>
Date: Wed, 19 May 2004 18:30:04 +0100

Hello all,

Just noticed the following behaviour in XOTcl:

Class Base
Base instproc foo {} {
     puts "Foo in Base"
}
Base instproc bar {} {
     # Just call foo
     my foo
}
Class Sub -superclass Base
Sub instproc foo {} {
     puts "Foo in Sub"
}
(Desktop) 56 % Sub a
::a
(Desktop) 57 % a foo
Foo in Sub
(Desktop) 58 % a bar
Foo in Sub

I was kind of expecting the last to say "Foo in Base", as the method
call of "foo" was dispatched from the Base class level. This is an
interesting problem, as I can see reasons why you might want to do the
current behaviour. However, I'm worried about some of the implications
of implementation details and name clashes. Suppose I implement some
class Base, which as part of it's implementation has a (private) method
DoStuff. Now suppose someone else sub-classes my class, and in their
implementation, they also happen to have a DoStuff method - this is
going to break my implementation. It seems like this is breaking
encapsulation somewhat. It seems like the cases where this dynamic
dispatch could be useful could also be solved by passing in an explicit
callback - that way you aren't relying on an implementation detail.

Am I missing a good reason for this? My OO theory is perhaps lacking in
this area. I can see that I can get around it easily by prefixing my
private methods:

Base instproc BaseDoStuff {...} { ... }

but this seems a bit ugly (reminds me of pre-namespace Tcl). Does XOTcl
have some other cool feature that I'm missing.

Cheers,

Neil.

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Tue, 5 Apr 2005 12:50:39 -0700

John McGlaughlin wrote:
> Can an extension be added to tkcon so that the interpreter becomes aware
> of XOTcl proc, instprocs and associated vars for type ahead capability.

tkcon only does the "first" level of expansion for procs. I
assume you are looking for object instrospection that will
expand methods and/or vars then?

> Lazy,

That I understand well. ;)

Jeff

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 04 Sep 2006 11:50:42 +0200

Scott,

you can achieve the precedence you are wanting by adding multiple
superclasses to Derived.
In the forthcoming version (which will be named 1.5), you can even use
"superclass add" like
in the following example.

  Class create Base
  Class create Derived -superclass Base
  Derived d
  puts [d info precedence] ;# ==> ::Derived ::Base ::xotcl::Object

  Class create BaseMixin
  Derived superclass add BaseMixin
  puts [d info precedence] ;# ==> ::Derived ::BaseMixin ::Base
::xotcl::Object

the new release is already passing the regression test. i will do some
more test
with the aolserver+OpenAce and make it available rsn.

best regards
-gustaf

Scott Gargash schrieb:
>
> Class create Base
> Class create Derived -superclass Base
> Derived d
> d info precedence ==> ::Derived ::Base ::xotcl::Object
>
> Class create BaseMixin
> Base instmixin add BaseMixin
> d info precedence ==> ::BaseMixin ::Derived ::Base ::xotcl::Object
>
> This behavior seems to violate encapsulation. BaseMixin is intended to
> intercept messages to Base. Derived doesn't know about BaseMixin and
> BaseMixin doesn't know about Derived, yet BaseMixin ends up being the
> first interceptor of messages to Derived.
>
> Since BaseMixin is intended to modify the behavior of Base, it would
> be better BaseMixin preceeded Base (and only Base) in the sort order.
>
> d info precedence ==> ::Derived ::BaseMixin ::Base ::xotcl::Object
>

From: <h8853209_at_wu-wien.ac.at>
Date: Mon, 03 May 2004 23:52:55 +0100

Read the attach.

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 6 Sep 2004 17:02:12 +0300 (EEST)

On Mon, 6 Sep 2004, Uwe Zdun wrote:

> I'm not pretty sure, what you want to reach here. The "eval" method provided
> by XOTcl does nothing
> else then a Tcl eval in the context of the object's namespace. This is not
> meant for evaluating
> methods, though it accidently works for local methods (procs), because they
> are defined
> in the same namespace.

OK, thanks. This is the information I was after. Ie. I should not assume
that, though it might be kind of cool if there was a way to do what I was
thinking.

> In the example below, I would define the " commands"
> such as 'format', 'short', 'object'
> as objects. Then you can use Tcl's eval to send messages to these objects,
> and define the first argument
> as method or use "unknown".

Then I actually gain very little compared to doing it inside namespaces.
It would've helped for the methods to know their context and also for
variables to be used (my first version did all this work manually). I can
still get that with directly manipulating Tcl namespaces, I think, but
it's just a tad more awkward than what I thought I'd get with XOTcl
objects (because I also have to create structures and objects for my
parser -- using namespaces instead of XOTcl obs).

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 26 Jan 2012 13:54:46 +0100

Dear Arthur,

this is a known problem area, already on our todo list.

What you are defining is an user-defined, slot-specific
parameter type.

In nx, object parameters are closer to the general parameter
handling (e.g. method parameters) than to accessors. The
parameters provide a rich set of configuration options
(value checkers, multiplicity, requiredness, ...). NX comes
with several built-in checkers/converters, which can be
extended with user-defined (scripted) checkers (see [1]).

For value checkers, a developer can decide, for which kind
of parameter a checker should be applicable. When a
value-checker is defined on the class nx::Slot, then this
checker can be used for method parameters in the same way as
for object parameters (see [2]).

[1]
http://next-scripting.org/docs/2.0b2/doc/nx/tutorial/index1#_value_constraints
[2]
http://next-scripting.org/docs/2.0b2/doc/nx/tutorial/index1#_slot_classes_and_slot_objects

Your example can be defined with a scripted checker as shown
below.

======================================================
nx::Class create Foo {
   :property bar {
     :type "bar"
     :method type=bar {name value} {
       puts stderr "assign called for $name $value"
     }
   }
}

set foo [Foo new]
$foo bar "test"
Foo new -bar "test"
======================================================

The checker is called here - as expected - twice.

In the more general case below, the converter is defined on
nx::Slot, therefore applicable for every parameter (e.g. for
property "bar" and for the method "abrakadabra").

======================================================
nx::Slot public method type=baz {name value} {
   puts stderr "assign called for $name $value"
}

nx::Class create Baz {
   :property bar:baz
   :public method abrakadabra {x:int y:baz,1..n} { return $x-$y }
}

set baz [Baz new]
$baz bar "test"
$baz abrakadabra 1 {a b c}
Baz new -bar "test"
======================================================


Since y of abrakadabra has defined the multiplicity 1..n,
the checker is called for every single value (in the snipped
above 5 times).

The new parameters are more powerful and general than the
xotcl-style "assign" method; so i tend to believe the latter
is obsolete. Some cleanup is here still necessary.

-gustaf neumann


On 26.01.12 12:06, Arthur Schreiber wrote:
> Hi everyone,
>
> When assigning an object's property using object parameters, the assign
> method of that property does not get called. Is that a bug or intended
> behaviour?
>
> See the following code:
>
> package require nx
>
> nx::Class create Foo {
> :property bar {
> :public method assign { object property value } {
> puts "assign called for: $object $property $value"
> }
> }
> }
>
> set foo [Foo new]
> $foo bar "test"; # assign method of the bar property is called
>
> Foo new -bar "test"; # assign method of the bar property is _not_ called
>
> Kind regards,
> Arthur
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Jonathan Kelly <jonkelly_at_fastmail.fm>
Date: Thu, 26 Jul 2012 13:09:06 +1000

Hi,

I'm trying to get nx working under windows. I was using Activestate 8.5
on an XP box ... and following the suggestion on the website I installed
MSVisualStudio 10.0 express ... but I couldn't see how to get that to
work ... there isn't a Makefile ... I had downloaded nsf2.0b3

So I thought I'd try cygwin (which I already use for other purposes). I
installed the compile tools, and ran configure, but it broke because I
apparently don't have a /usr/local/include/tcl8.5/tools/genStub.tcl ...
I took a gamble and downloaded a version I found on the web somewhere,
and then configure ran but with some warning messages. Make then breaks
with this

./generic/nsfError.c:116: error: conflicting types for 'NsfPrintError'
./generic/nsfDecls.h:73: error: previous declaration of 'NsfPrintError'
was here
./generic/nsfError.c:116: error: conflicting types for 'NsfPrintError'
./generic/nsfDecls.h:73: error: previous declaration of 'NsfPrintError'
was here
Makefile:575: recipe for target `nsfError.o' failed

I'm happy to be the guinea pig for getting the "use NX on windows"
instructions to be useable.

Or should I just use XOTcl ... ?

Thanks
Jon.

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 6 Oct 2004 23:26:33 +0200

Hi Attilio,
if i would be Mr Spock, i would say "fascinating".

The example can be simplified to:

   set pippo 1
   Object o
   puts [o exists pippo]
   Object o::p
   puts [o exists pippo]

and was like this already at least in 0.9 (in 2001),
most likely as well in all versions supporting "exists".

For the time being, you can use:

  Object instproc exists var {
    string compare [my info vars $var] ""
  }
  puts [o exists pippo]
  o set pippo 1
  puts [o exists pippo]

It should be fixed properly in the forthcoming release.

best regards
-gustaf


On Wednesday 06 October 2004 17:38, Attilio Dona` wrote:
> Hy Gustaf and Uwe,
>
> We have the following bug:
>
> package require XOTcl
> namespace import xotcl::*
>
> xotcl::Class::Parameter create Param -parameter {
> {value ""}
> }
>
> Class create MA -superclass Class
>
> MA parameter {{v -Class {Param -value ciao} -default 1}}
>
> MA create A
>
> puts "A exists pippo: [A exists pippo]"
>
> set pippo 10
>
> puts "A exists pippo: [A exists pippo]"
>
>
> --> A exists pippo: 0
> --> A exists pippo: 1
>
> This is true if you have at least one parameter defined for a Metaclass
> and for every global variable defined!
>
> ciao
> Attilio
>
>
>
>
> --------------------------------------------------------------------
>
> CONFIDENTIALITY NOTICE
>
> This message and its attachments are addressed solely to the persons above
> and may contain confidential information. If you have received the message
> in error, be informed that any use of the content hereof is prohibited.
> Please return it immediately to the sender and delete the message. Should
> you have any questions, please contact us by replying to
> webmaster_at_telecomitalia.it.
>
> Thank you
>
> www.telecomitalia.it
>
> --------------------------------------------------------------------

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik und Neue Medien
Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sun, 4 Jan 2004 10:23:03 +0100

>
> It seems that I have subscribed to this problem :-)
> This time it is on a debian/linux (an old one) where xotcl 1.0.2
> was successfully compiled (although make test hangs, I don't know why).
>
> It's the same symptom:
> A Tk window built by a command either is correctly displayed if the
> command is called directly from the "wish", or causes a seg fault if the
> command is called from a Tk menu.
> I have compiled xotcl/tcl/tk/itk/itcl with --enable-symbols
> (I haven't recompiled other libraries such as blt though). Unfortunately,
> my gdb is broken - but since the symptom is the same, here is the report
>
> of gdb for the last time it happended (it was tcl 8.3 and now it is 8.4):
> > #0 0xfed5c580 in Tcl_PopCallFrame () from /local/lib/libtcl8.3.so
> > #1 0xfed69950 in TclObjInterpProc () from /local/lib/libtcl8.3.so
> > #2 0xfed61f98 in EvalObjv () from /local/lib/libtcl8.3.so
> > #3 0xfed625dc in Tcl_EvalEx () from /local/lib/libtcl8.3.so
> > #4 0xfed627cc in Tcl_Eval () from /local/lib/libtcl8.3.so
> > #5 0xfed28114 in Tcl_GlobalEval () from /local/lib/libtcl8.3.so
> > #6 0xfee26058 in Tk_BindEvent () from /local/lib/libtk8.3.so
> > #7 0xfee2aaac in TkBindEventProc () from /local/lib/libtk8.3.so
> > #8 0xfee308a0 in Tk_HandleEvent () from /local/lib/libtk8.3.so
> > #9 0xfee30ca4 in WindowEventProc () from /local/lib/libtk8.3.so
> > #10 0xfed5f960 in Tcl_ServiceEvent () from /local/lib/libtcl8.3.so
> > #11 0xfed5fcf8 in Tcl_DoOneEvent () from /local/lib/libtcl8.3.so
> > #12 0xfee30d08 in Tk_MainLoop () from /local/lib/libtk8.3.so
> > #13 0xfee3bb7c in Tk_MainEx () from /local/lib/libtk8.3.so
> > #14 0x2be9c in main ()
>
> So, if anyone has an idea of why this happens everytime I reinstall
> xotcl... :-(
>

The same stack dump I have got with 1.1.1.
I used also callbacks from Tk.
I could find out that it crashed in context of additional instmixinst but only
by 1.1.1
Herr Neumann send me pre realease of 1.1.2 with some explanation.
In Version 1.1.1 the insmixins treads the frame in same way as filters in pre
1.1.1.
With 1.1.2 it do not crash any more but I do not know if the problem was fixed
or the instmixinst works as in 1.0.2.

Do you use filters in context of Tk callback?
If yes, you can try to remove temporary the filters and look if the crash
happen.

Artur Trzewik