Weblog Page

From: Sheik Yussuff <sheik_at_carib-link.net>
Date: Wed, 5 Sep 2001 17:05:46 -0300

Consider the following program fragment:(Win 98 ver 0.85) where:
1. X has subclasses B and C
2. X has instproc m
3. object a mixes in {C B}
4. message p sent to object a(see code below)

The code produces as answer:
   method p of A
   method m
   method m of A

I expected:
   method p of A
   method m
   method m
   method m of A

Apparently only the method m inherited by C is executed
while the method m inherited by B is not!!
Any help to clarify this situation is appreciated.

Thanks.

Regards,
--sheik
-----------------------------------------------------------------
# Code to illustrate above.

Class X
X instproc m args {
  puts "method m"
  next
}

Class A
A instproc m args {
  puts "method m of A"
  next
}

A instproc p args {
  puts "method p of A"
  [self] mixin {C B}
  [self] m
}

Class B -superclass X

Class C -superclass X


A a
a p

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 03 Nov 2011 14:14:42 +0100

Announcing XOTcl 1.6.7
*************************

Dear XOTcl Community,

We are pleased to announce the availability of XOTcl 1.6.7
This release is just a bug-fixing release of the XOTcl 1.*
series.

Changes relative to 1.6.6 are:

     * fixed potential crash in "namespace delete"
     * fixed potential crash in autoname
       during cleanup
     * fixed bug in filters, when filterchain reaches end
without finding
       the method to be invoked
     * fixed handling of object-names containing semicolon
in serializer
     * handling implicit deletes
     * some code cleanup

  All new development efforts are concentrating on the Next
scripting framework,
  including XOTcl 2.0 (see http://next-scripting.org)

MORE INFO
   General and more detailed information about XOTcl and its
components
   can be found at http://www.xotcl.org

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 13 Jan 2001 17:03:06 +0200 (EET)

According to the XOTcl language reference the alloc method is an instproc
of Class, yet:

% Class Foo
Foo
% Foo alloc bar
alloc
%

Ie. the instance of Class called Foo does not recognise the alloc method,
and creates an object named alloc instead. If alloc is actually a proc of
Class, is there any way to avoid the normal create procedure in the code
above?

         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

From: Hal Heisler <hh_at_heisler.net>
Date: Thu, 18 Oct 2001 14:14:28 -0700

Hello,

I'd like to use xotcl with tclkit. When I try to load the distributed linux binary libxotcl.so I see
undefined symbol: tclEmptyStringRep

I have not tried building xotcl myself yet, perhaps that's what I need to do. Tclkit uses a tcl/tk 8.4 snapshot from cvs.
 
Just wondering if anyone's been down this road.

Thanks,
Hal

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 24 Apr 2001 15:16:20 +0200

On Sunday 22 April 2001 14:02, Artur Trzewik wrote:
> Hallo
>
> By building some Xotcl Class System I have following problem.
> Consider the example
>
>
> % Class A
> A
> % A proc test {} { puts "method test" }
> % Class B -superclass A
> B
> % B test
> test
> %
>
> I would expect by calling B test to invoke A proc test and not to create
> new instance of B.
> I know this bahavior from Smalltalk. It is very usefull for building
> special creating method on class side or some method that not need a
> instance

 we discussed internally this topic about forteen day ago internally.
 the point is that
   - "proc" is by its idea an object specific method
   - the way to provide methods for other objects (in the general sense)
     in xotcl is primarily the instproc mechanism;
   - the preferred way to provide methods for classes
     are meta classes

 one can use meta-classes, or even if you want to stick with
 "Class" class creation, you can combine metaclasses with instmixins
 to achieve a similar behavior:
==========================================================
Class M
M instproc mt {} {puts "method meta test" }
Class instmixin M

Class A
Class B -superclass A
B mt
==========================================================

 in other cases, it is appropriate to search for some base-class
 an to call its proc via delegation. The per-object-philosopy
 (for the "eyes" of one object only) is something which can be
 desireable in some situations.

 a possible solution is to distinguish between
    - proc
    - instproc
    - classproc
 where the last one is like a proc, which is intherited to subclasses.
 The danger i see there is the XOTcl becomes a kind of new version
 of CLOS, which allows a very elementary configuration of all
 aspects of the language with tons of "modifiable language elements"

 aside the basic question of conceptual cleanness of what procs are
 supposed to be is the question of negative effects and compatibility.
 Currently, calling a proc is very fast, the necessity to search for
 another proc will cause some speed penalty. for other effects,
 check the following incomplete list of further aspects:

   - method chaining between procs (of classes),
   - [self] of a proc is not alway the object, on which it is called,
   - inheritable procs in per-object or per-class mixins

 My feeling is that the number of occurances, where this inheritable
 procs are needed, is rather small (maybe it is my programming style).
 The issues involved are quite complex. in most (all) there is a
 not-so-conveniant, but quite-clean solution for the problem. But
 my opinion is quite undecided.

 What is the opinion of the community? Do you need/want such
 an extended "inheritable proc" or a new language-consttruct?
 Did you face this problem already, and if yes, was it hard/inelegant
 to solve?

 best regards
 -gustaf

From: Kristoffer Lawson <setok_at_scred.com>
Date: Sat, 22 May 2010 01:12:43 +0300

On 22 May 2010, at 00:20, Victor Mayevski wrote:

> With your project people need to learn what MVC is, how it works
> etc. I tried to look at your examples and I could not understand at
> all how it works. I suspect that there is prior knowledge of other
> things required to grasp what you are trying to accomplish. And your
> assumption is that most people already have that knowledge. I don't
> know about others, but I probably don't have that knowledge,
> although I understand the http/html very well.

You're right. But to be fair, I just haven't had time to write all the
documentation and stuff. I don't intend to keep it this way. As the
README says, this is 100% pre-beta early alpha stuff. However, it does
work. FWIW I just added a tiny bit more documentation in there. One
reason to not write too much in the way of a "user manual" yet is that
this is work in progress. Things might still change.

So definitely at some point I want some diagrams and clear mini
tutorial and stuff. I don't want to assume everyone knows MVC and my
thinking! However, if you look at the README and check the examples,
you might figure it out, as it's a simple but effective model. But
yeah, prior knowledge of the MVC pattern does help you along at this
stage — in particular Apple's Cocoa has had some influence.

> My suggestion is that you provide very simple examples that explain
> what each example does (what/how/why).

Take a look at that and the 'foo' widget. It is linked to the '/foo'
URL and contains the 'bar' widget (sure the names could be better :-)
within it, that it uses.

FooController has a method "setName" which is connected to the POST
with the appropriate submit name ("submit-setName"), which would be
submitted to '/foo'. The method is called with the form data built
into a FooNameForm object when the user submits their name into the
form. FooController also has a method "world", which is connected to
the URL '/foo/world'. That gets called when that URL is accessed. Here
both of those methods are dead simple, just setting internal things
inside the Controller (perfectly fine), but they could do stuff like
write to database, have checks on the data, decide to switch the sub-
widget to be shown ('bar' here), or whatever else.

If the user accesses '/foo/world' or submits the form, the related
methods get called *before* rendering. Their responsibility is thus
not to render the HTML, but to set stuff within FooController. Then a
separate View object (basically defined in this case by the template
foo/view.tml) fetches information from that Controller instance, and
renders it out.

That template model is very different from the normal way e.g. Django
does it, where you pass in information to the template and where
basically control and render are kind of the same thing (annoyingly
Django uses the 'view' term to cover everything). I've done a fair bit
of Django coding and this can get incredibly messy. I've grown to
really dislike it and effectively began to write my own web framework
on top of Django which we may still use for Scred.com :P

Anyway my solution means that the functionality and control of the
application and its components are completely separated from the
rendering. This is a Good Thing and offers great flexibility, code
reuse and power. Believe me, with large projects this is the way to
go, but also adds a great model for quick and small apps too. It's
also great because you can test the "back end" of a website with good
unit tests, without caring about the rendering at all — and those
tests are often the most important ones. Additionally you can also
test the Views separately, by giving them static Controllers with
exactly the test data you want. They'll just render it out and you can
have tests to see they're doing it correctly.

Each page can be formed from multiple widgets, and each widget can
have more widgets within. Each level controls the widget by talking to
its controller. The rendering is done automatically later by going
through each widget and telling its View to give out the HTML (takes
place in the template with the [widget] command).

Sorry for this crummy explanation, but it's been a long day and I'm
half asleep! As mentioned, I do plan really clear and proper
documentation. But for now I'll just have to say it's a cool way to do
things :-)

As for the Ruby / Tcl thingy ... first I've ever heard of it. Got any
pointers to it?

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

From: Victor Mayevski <vitick_at_gmail.com>
Date: Wed, 27 Oct 2010 15:48:32 -0700 (PDT)

Excellent, exactly what I needed.

Thank you


----- Original Message -----
From: "Gustaf Neumann" <neumann_at_wu-wien.ac.at>
To: xotcl_at_alice.wu-wien.ac.at
Sent: Tuesday, October 26, 2010 11:53:26 PM GMT -08:00 US/Canada Pacific
Subject: Re: [Xotcl] non positional argument

On 26.10.10 23:23, vitick_at_gmail.com wrote:
> Is it possible to have a non-positional argument that is optional and its variable is only set when it is present as the argument to the method. Otherwise, it is ignored, no error.
> Basically, I want it behave like an option to the method but without specifying any value.
...
> Or, it can even be a boolean, set to 1 if it was specified and set to 0 if not. That would be even better, shorter code.
see below for some optional argument handling. i guess you
want m2.
-gustaf neumann

=====================================
Object create myobj {
   :public method m1 {-test} {
     puts "m1 test exists [info exists test]"
   }
   :public method m2 {-test:switch} {
     puts "m2 test exists [info exists test] value $test"
   }
   :public method m3 {test:optional} {
     puts "m3 test exists [info exists test]"
   }
}

myobj m1
myobj m1 -test 1
myobj m2
myobj m2 -test
myobj m3
myobj m3 1
=====================================

output is

=====================================
m1 test exists 0
m1 test exists 1
m2 test exists 1 value 0
m2 test exists 1 value 1
m3 test exists 0
m3 test exists 1
=====================================

_______________________________________________
Xotcl mailing list
Xotcl_at_alice.wu-wien.ac.at
http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 24 Feb 2006 11:35:30 +0100

mail_at_xdobry.de schrieb:
> Learnable lazy wrapper per unknown mechanism.
> Should one do such magic thinks?
>
one can use "unknown" by itself for implementing the task, or to
register a forwarder (i have used the same approach in
http://wiki.tcl.tk/11033).

I am not a particular friend of unknown, except for error handling.
i see three reasons against it.

1) "unknown" does not mix well with mixins. The program semantics
    can change, when mixins are added (see below)
2) only unknown commands are forwarded. What if you want to
    forward a method, that happens to be defined by some classes.
    Try to forward e.g. append by this approach (somewhat related to (1)
3) all unknown commands are forwarded (can easily be fixed)

generally i prefer to use the explicit "create" over the unknown handler
to create objects (using "Object create o1" instead of "Object o1"),
except that the shortcut is much nicer to read. If one defines user
methods on classes, the unknown is dangerous as well, one might
define a method o1, typos can easily turn up as created objects.

This as a side node "unknown considered harmful".

So, the apporach via "unknown" is interesting, but has its dangers.
It only buys us a slight optimization by delaying the generation of the
forwarders. Note, that the forward command only registers a command
and is fairly efficient (comparable with a single eval).

To be complete, yet another approach is to use filter or instfilters,
here a filter solution:

   Class Queue -array set forwarder {clear 1 get 1 put 1 peek 1 unget 1
size 1}
   Queue instproc qfilter args {
     if {[[self class] exists forwarder([self calledproc])]} {
       return [eval [self]::queue [self calledproc] $args]
     }
     next
   }
   Queue instproc init {} {
     ::struct::queue [self]::queue
     my filter qfilter
   }
   Queue instproc destroy {} {
     [self]::queue destroy
     next
   }

-gustaf

ad 1) If we take the example based on unknown and add a mixin,
 as with this tricky oneliner

   Class M -instproc get args next
   Class Queue -parameter {{queue [self]::queue}} -instmixin M

  then the command "get" is defined, therefore "unknown" is not called
  when "myqueue get" is invoked. Therefore, there will be no forwarding
  to the queue...

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 16 Apr 2004 19:54:59 +0200

On Friday 16 April 2004 17:19, Attilio Dona` wrote:
> Hy,
>

> 2 Parameter strange behavoir
>
> When using Parameter command I have noticed same strange behavoirs, for
> examples:
>
> case 1:
> Class X -parameter {{-x 100}}
>
> ::X

 Attilo,
 can it be, that your intention was to use

    Class X -parameter {{x 100}}

 note, the parameter is named "x", not "-x".
 To create an instance, you can use
   
         X create obj1 -x 100

 I would not recommend to name a parameter "-x".

-gustaf

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Mon, 1 May 2006 16:35:26 -0600

Hello,

I've run into an issue when trying to remove a mixin from an object. It appears that removing a
mixin from an object interacts with the method chaining, such that the "next" isn't invoked.

Here's an example:

Class Mixin1
Mixin1 instproc destroy {args} {
  puts "Mixin1 1: [my info mixin]"
  next
  my mixin delete ::Mixin1
  puts "Mixin1 2: [my info mixin]"
}

Class Mixin2
Mixin2 instproc destroy {args} {
  puts "Mixin2 1: [my info mixin]"
  my mixin delete ::Mixin2
  puts "Mixin2 2: [my info mixin]"
  next
}

Class Mixin3
Mixin3 instproc destroy {args} {
  puts "Mixin3 1: [my info mixin]"
  my mixin delete ::Mixin3
  puts "Mixin3 2: [my info mixin]"
  next
}

Object a

puts "a: [a info mixin]"
a mixin set {::Mixin1 ::Mixin2 ::Mixin3}
puts "a: [a info mixin]"

a destroy


And the output is

a:
a: ::Mixin1 ::Mixin2 ::Mixin3
Mixin1 1: ::Mixin1 ::Mixin2 ::Mixin3
Mixin2 1: ::Mixin1 ::Mixin2 ::Mixin3
Mixin2 2: ::Mixin1 ::Mixin3
Mixin1 2: ::Mixin3


Because Mixin1 invokes "next" before "mixin delete", Mixin2's "destroy" method gets invoked. But
since Mixin2 invokes "mixin delete" before "next", Mixin3's "destroy" method is not invoked, despite
it remaining in the object's list of mixins.

This is not the behavior I would expect, and I can't find it documented anywhere. Is this the
intended behavior? What should I do if I want to remove a mixin and then continue executing chained
methods.

      Scott

Notice
The information in this message is confidential and may be legally privileged. It is intended
solely for the addressee. Access to this message by anyone else is unauthorized. If you are not
the intended recipient, any disclosure, copying or distribution of the message, or any action
taken by you in reliance on it, is prohibited and may be unlawful. If you have received this
message in error, please delete it and contact the sender immediately. Thank you.