Weblog Page

From: Neophytos Demetriou <k2pts_at_cytanet.com.cy>
Date: Wed, 16 Apr 2003 09:39:06 +0300

Hi Michael (of nstcl fame right?),

it's glad to see you in this list. I'm sure Gustaf or Uwe will have a
better response for you but here's what I do:

AFAICS, static member variables are not supported as a language
construct but you can either have a variable in the "Chapters" class, e.g.

Class Chapters

Chapters set current_chapter 12345

which can be fetched using [Chapters set current_chapter] from any other
object or class or from an instance you can get/set the value as follows:

Chapters aChapter

[aChapter info class] set current_chapter 4567

puts [[aChapter info class] set current_chapter]

Now, suppose you have a Class instproc say printCurrentChapter:

Chapters instproc printCurrentChapter {} {

    puts [[my info class] set current_chapter]
}

aChapter printCurrentChapter


I hope that helps.

Best wishes,
Neophytos


Michael A. Cleverly wrote:

>(Disclaimer: I'm quite new to XOTcl & I have read the tutorial a couple
>times but maybe not enough. :-)
>
>What's the XOTcl idiom/way for a static member variable (what snit, the
>only other OO Tcl package/extension I've used, would call a "type
>variable")?
>
>Contrived example: if I had a "Chapters" class, I'd like to have a single
>variable, accessible by all instances of the class, that kept track of the
>"current" chapter. Suggestions?
>
>Michael
>
>_______________________________________________
>Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
>http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
>
>
>
>

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Fri, 15 Sep 2006 11:28:50 -0700

I have some classes that are defined in C using the xotcl (cersion 1.4) C
API. Things seem to work (I can create objects and invoke methods), but I
can't get chaining to function. I can invoke the "next" command (using
Tcl_Eval( interp, "xotcl::next")), but that fails with "next: can't find
self"

I've stepped into the XOTcl code and it looks like it's searching the the
interpreter's call stack to determine the active object but as near as I
can tell, my C-defined methods don't correctly annotate Tcl's call stack.

I'm not aware of any documentation for the C API, so I used the library
code (xotclsdbm.c) as an example. Is there anything I need to do beyond
XOTclAddIMethod to get "next" to function? I'm using a locally built
version of XOTcl (the binary versions don't include header/libs). Is it
possible I've built something incorrectly? I see two defintions for the
RUNTIME_STATE macro which looks like it plays a role in this. I don't
know which version I'm using or if it even matters, but I assume I'm using
the default version.

        Scott

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Wed, 26 Sep 2001 11:49:33 +0200

On Tuesday 25 September 2001 06:16 pm, you wrote:
> On Tue, 25 Sep 2001, Uwe Zdun wrote:
> > b) make filters special objects which have a method (proc) on them which
> > is the filter. This would be a substantially different model to what we
> > have now. Filter search would have to take place on these objects,
> > filters would not be inherited, linearization of filters would be
> > different, etc. But, of course, we could combine different filters on
> > these objects. This would be closer to cross-cutting concerns in AOP.
>
> Could you not still keep inheritance in this model? The only difference
> really would be that the filters themselves would be reusable
> components. If attached to a class, then all class methods, and anything
> extending the class, will be affected by the filter. Or is there something
> wrong with this idea?
>

no, in principal not ... to clarify things, what you mean is:

Object filters
filters proc f1 args {
  ...
}
filters proc f2 args {
  ...
}

Class X
X instproc xf args {...}
X instfilter {xf filters::f1}


- if "::"'s are in the filter name, we only search
for procs on objects during filter search.

- [self class] is "" in f1, f2?

- good old instproc filters, such as xf, still work
or are all filters object procs?

- what are potential benefits to a Class

Class filters
filters instproc f1 args {
  ...
}
filters instproc f2 args {
  ...
}

which we use e.g. as superclass or instmixin (what will work fully in the
next release)?

--uwe

-- 
Uwe Zdun
Institute for Computer Science, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_uni-essen.de

From: Sheik Yussuff <sheik_at_carib-link.net>
Date: Sat, 21 Jul 2001 23:41:17 -0300

Class A is a derived class of meta-class Consultation.
In the filter conFilter I would like to obtain
the class of the object that received the message "m"
when invoking the command: [a m 123]. That is, the
class of the original receiver of method "m".
(Please see code below).

Thanks for any help.

Regards
sheik
.........................................................
#Code:
Class Consultation -superclass Class

Consultation instproc conFilter args {
  set method [self calledproc]
  
  #The following is of course not correct!
  #[self class] evaluates to Consultation;
  #I need it to evaluate to A. Help!!

  if {[[self class] info instprocs $method] == ""} {
    if { [[self] exists delegate] } {
      return [eval [[self] set delegate] $method $args]
    }
  }
  next
}

Consultation instproc init args {
  [self] instproc setDelegate {d} {
    [self] set delegate $d
  }
  next
  [self] filterappend [self class]::conFilter
}

Consultation A -parameter delegate


A instproc m {x} {
  puts "[self] [self class] [self proc] $x"
  return [next]
}

Class B
B instproc m {x} {
  puts "[self] [self class] [self proc] $x"
  return [next]
}

A a
B b
a setDelegate b
# send message m to object a
puts "result = [a m 123]"

From: Aamer Akhter <aakhter_at_gmail.com>
Date: Wed, 6 Oct 2004 08:24:15 -0400

Hello,

Has anybody run into weirdness with the komodo tcl debugger and xotcl?
Sorry to be so imprecise, but that's the best way I can describe it
right now.

-- 
Aamer Akhter / aakhter_at_gmail.com

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Mon, 29 Nov 2004 19:30:36 -0800

BTW, use the attached patch - very small, unimportant diff
between the two (but less verbose at one point).

Jeff

> -----Original Message-----
> From: xotcl-bounces_at_alice.wu-wien.ac.at
> [mailto:xotcl-bounces_at_alice.wu-wien.ac.at] On Behalf Of Jeff Hobbs
> Sent: November 29, 2004 7:28 PM
> To: xotcl_at_alice.wu-wien.ac.at
> Cc: 'Andreas Kupries'
> Subject: [Xotcl] xotcl-1.3.3 Makefile / configure fixes
>
>
> Attached is a patch to xotcl to make it build better. The
> changes are to correct the build and install both on unix and Windows.
>
> The fixes correct:
>
> * installation when built outside source directory
> * build and installation on Windows using TEA
> * more clarity during install-libraries
>
> The addition of VISUAL_CC to the defines on Windows
> highlights a generally incorrect usage of Windows-checking
> constructs. You can add things like
>
> #ifdef _MSC_VER
>
> in your C code, or better yet it should simply switch on:
>
> #if defined(WIN32)
>
> which tcl.h defines, and for the USE_MALLOC case, something
> like this should suffice:
>
> #if defined(WIN32) && !(defined(__GNUC__)
>
> but the changes I made work, just in a less favorable way.
>
> Jeff Hobbs, The Tcl Guy
> http://www.ActiveState.com/, a division of Sophos

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Tue, 13 May 2003 11:44:10 +0200

maybe, what you have overlooked in my patch was that there is a "return"
in:

    if {![info exists success]} {
        #puts stderr "Cannot locate the XOTcl library on your system!"
        return
    }

BTW, ::xotcl::lib is always set at this point. Before the method
"check_library_path", xotcl.c sets it to the compiled-in default. the
auto_path should only be changed if we learn in check_library_path that we
want to change it (and not to the compiled-in default). The code below
does not work, because you use the wrong package name:

% package require XOTcl
1.0
% namespace import ::xotcl::*
% package require package
can't find package package
% package require xotcl::package
0.91

the C findXOTcl searches for the xotcl .so/.dll and is not related
to the "check_library_path" method. Its only used in the xotclAppInit.c
fake shell, not in xotcl.c

I would still propose the patch from yesterday.

--uwe

On Monday 12 May 2003 22:14, Gustaf Neumann wrote:
> On Monday 12 May 2003 20:04, Uwe Zdun wrote:
> > Looking through this code again, the ::xotcl::lib is not really used in
> > XOTcl's code anymore ...
>
> hmm? The line after the error message says:
> set ::auto_path [concat $::xotcl::lib $::auto_path]
> if the variable is not set, you get the error message there.
> it is certainly possible to set a default value, say from the
> configure prefix....
>
> The more sensible change is to use the patch below, which will
> be ok, when you load xotcl via xotclsh, but will not find xotcl
> packages, when xotcl is loaded via tclsh; try:
>
> tclsh
> package require XOTcl
> namespace import ::xotcl::*
> package require package
>
> Currenty, xotcl does a patch checking in C (findXOTcl.c) and
> in tcl (predefined.xotcl). my hope was rather to get rid of the c-code...
> The background of this code is as follows:
> - tcl searches the libraries in auto_path and the subdirs of that.
> - with xotcl i would like the get one more level to organize the
> xotcl packages more nicely.
> - therefore the xotcl library is added to the auto_path.
> We would not need the library, when we assemble a large
> tclIndex.tcl file in the xotcl directory. Maybe that is the better
> way... we will check this more carefully...
>
> best regards
> -gustaf
>
> -- predefined.xotcl~ 2003-04-24 22:49:14.000000000 +0200
> +++ predefined.xotcl 2003-05-12 21:48:20.000000000 +0200
> _at_@ -357,12 +357,9 @@
> }
> }
>
> - if {![info exists success]} {
> - puts stderr "Cannot locate the XOTcl library on your system!"
> - return 0
> + if {[info exists ::xotcl::lib]} {
> + set ::auto_path [concat $::xotcl::lib $::auto_path]
> }
> - #puts stderr "[info exists success] <$::xotcl::lib>"
> - set ::auto_path [concat $::xotcl::lib $::auto_path]
>
> #
> # and forget all "xotcl::" packages in Tcl's packageTable so that they

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

From: <mail_at_xdobry.de>
Date: Thu, 05 Jul 2007 13:12:11 +0200

>Strictly speaking, an application programmer does not have
>to use parameter in the application program, therefore Artur is right.
>
>While the application program does not have to *define* slots,
>it is hard to do something useful in xotcl without *using* slots
>since methods like "superclass", "class", "mixin" etc.
>are implemented as slots.
>
Thanks for precise explanations.
I must confess that till now I have not consciously (bewußt) used slots.
It is indeed very powerful construct and I have noticed that is used
to implement of many of XOTcl features.
One reason, why I do not use slots and complex parameters is
that XOTclIDE has no support for it. I has not programmed it yet.
I have no idea how to define or visualize slots in XOTclIDE in
this way, that it suits to general concept.
Now XOTclIDE has already a problem with versioning of class definition (creation body).
Because definition bodies are not versioned like bodies of methods.
Using slots is even more complex.
Tutorial example:

Class create A -slots {
    Attribute foo -default 1 -proc assign {domain var value} {
      if {$value < 0 || $value > 99} {
        error "$value is not in the range of 0 .. 99"
      }
      $domain set $var $value
    }
}

Normally XOTclIDE let you view, change and redefine all items separately. But in this example complex items like method-body are part of class creation.
Is there a way to define such slots in iterative way.
I have tried following code but it was not OK.

Class A
Attribute A::slot::foo

this one seems to work

A slots {
   Attribute foo
}
A::slots::foo proc assign {...} {
   ....
}

I miss also possibility to obtain slot definition per introspection.
(similar to ::A info parameter)
Probably one the only one way is own code (::A::slot::foo info body assign).

Anyway!
Probably one of possible usage of slots will be implementing
MVC GUI Framework.
Complex parameters could be used to connection GUI Code with
Domain Code.
Similar approach I know from Smalltalk VisualWorks Framework
see also:
http://www.martinfowler.com/eaaDev/uiArchs.html
It use so called Attributes, which are objects and represent
a simple value (like Integer, String, Date).
UI-Controls can be connected to this attributes (per event framework).
These attributes are members of domain objects.

I have a question to another XOTcl users.
I am not sure how urgent and important is the support of slots
definition in XOTclIDE.
So any information about it are welcome.

Artur

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Wed, 6 Jun 2001 10:27:06 +0200

On Tuesday 05 June 2001 21:44, Gustaf Neumann wrote:
> Dear XOTcl community,
>
> If you have interest to get access to the current development
> version of XOTcl (which is exactly 0.85-p1) you can use bitkeeper to
> get the source tree. Bitkeeper (http://www.bitkeeper.com) is
> an open source version control system.
>
>

Hopla !
This "BitKeeper" is a commercial product requiring license ?

From: Zoran Vasiljevic <zv_at_archiware.com>
Date: Thu, 5 Oct 2006 11:11:24 +0200

On 05.10.2006, at 01:07, Gustaf Neumann wrote:

> Rather than proposing any kind of OO language, i would suggest
> to add a framework to the core, that every extension
> (including XOTcl) can use. This framework is not useful as an
> OO language on its own, but an environment that can host multiple
> OO languages in parallel, such as Snit or XOTcl (maybe the
> language from current TIP 257 as well), without pushing a single
> model.
> Languages like Snit or XOTcl can continue to develop, the core
> developers can optimize and integrate better with the tcl-core, etc.

What I think is equally important is to have a kind-of
bare-bones (or minimal, if you will) OO system built
into Tcl _alone_.
You know, many people will just use Tcl aw-is i.e. w/o
any extension(s). This is what DKF is trying to push,
as (the absence of) OO-stuff is making Tcl look
inattractive to some folks.

If you could have a minimal _usable_ OO language just on
the basis of your proposition (even when this would be
a simple thin Tcl layer distributed by Tcl distro) that
would of course beat all arguments from the "other camp".

Cheers
Zoran