View · Search · Index
No registered users in community xowiki
in last 10 minutes

Weblog Page

Showing 1011 - 1020 of 1561 Postings (summary)

Re: [Xotcl] Help with singleton design pattern

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Tue, 22 Apr 2003 22:17:06 +0200

Hi,

I just had the idea for yet another Singleton variant that was not exactly
planned for in the XOTcl design, but seems to work fine: an object that has
itself as a class (and Class as a superclass so that it stays a class):

% Class A -superclass Class -class A


that means it can define instprocs on it and dispatch them directly:

% A instproc aProc args {puts ****}
% A aProc
****
 
procs do also work:

% A proc bProc args {puts ++++}
% A bProc
++++

and you can derive a subclass from the Singleton:

% Class B -superclass A
::B
% B b
::b
% b aProc
****

and it conforms to the "Singleton definiton" (a class that has just one
instance).

--Uwe



On Tuesday 22 April 2003 21:21, Artur Trzewik wrote:
> Hallo!
>
> As singleton objects I often use Objects directly derived from Object
>
> Object MySingleton
> MySingleton proc doJob {} {
> puts "This is my job"
> }
>
> MySingleton doJob
>
> This is not singleton pattern but is same cases you do not need some
> Java, C++ solution.
> One disadvantage is that you can not use method inheritance.
>
> By the way.
> The presented solution from G. Neumann.
> That is to overwrite "new" method that returns singleton object
> is the standard way to implements singleton in Smalltalk
> (the singleton instance is saved in class variable Default).
> That is XOTcl! "new" is just method not special operator and can
> be overwritten.
>
> Artur Trzewik
>
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
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

Re: [Xotcl] Loading XOTcl crashes

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Wed, 13 Jun 2012 09:16:34 +0200

When everything works from the shell, and it works with
Komodo V6 and it does not work with Komodo V7, then it
certainly looks like a problem with Komodo V7. We do not
have Komodo here, which is a commercial product (most likely
with a commercial support). Is the a public visible forum
with your discussions, maybe i can get a clue from it...
 From the snippet below, there seems to be a problem with
the error handling (where i see nothing special from the
xotcl side).

-gustaf neumann

On 13.06.12 02:33, Kurt Stoll wrote:
> (I realize that this is probably not an XOTcl issue, but a ActiveState Komodo issue; however, I have not been able to find an answer through ActiveState, so I may have better luck here.)
>
> Running on a Mac, using OSX V10.7.4.
>
> I cannot get XOTcl to load properly with ActiveState Komodo V7. I do not have any problem with V6 of that tool. Also, loading XOTcl into tclsh when invoked from the Terminal works. All three environments (Komodo V7, V6, and Terminal / tclsh) are using the same version of Tcl (8.5) and the same version of XOTcl (1.6.6 - I know, down rev by one release). All three versions point to the same library file: /System/Library/Tcl/8.5/xotcl1.6.6/libxotcl1.6.6.dylib.
>
> Yet, when I attempt to load XOTcl (using package require XOTcl) from Komodo V7, it gets stuck in an infinite loop:
>
>
> Error in predefined code
> too many nested evaluations (infinite loop?)
> while executing
> "DbgNub_infoCmd exists DbgNub(returnState)"
> (procedure "catch" line 11)
> invoked from within
> "catch {set savedErrorInfo $::errorInfo}"
> (procedure "::unknown" line 18)
> invoked from within
> ...
> "proc ::xotcl::myproc {args} {linsert $args 0 [::xotcl::self]}"
> too many nested evaluations (infinite loop?)
>
>
> I don't believe I have changed any relevant settings.
>
> Any clues?
>
> Thanks,
> Kurt Stoll
>
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

[Xotcl] Re: [Xotcl] Classes and namespace

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 30 Jan 2001 16:06:39 +0200 (EET)

On Tue, 30 Jan 2001, Uwe Zdun wrote:

>
> XOTcl classes actually consist of two namespaces, one for the class object
> (where procs and class variable are defined) and one for the class features
> (where the instprocs are defined). The later one is "hidden" in the namespace
> "XOTclClasses". So during execution of the "init" method the current namespace
> is:

OK, I understand that now and see how it's problematic. However it's
still somehow confusing from the developer's point of view that what
syntactically appears to be in the same namespace isn't (not your
fault, I know :-). I really can't see any way round it, though... ?

In any case, an [info ns] command might be clearer in this case
than [info parent] -- even though they give the same result. parent
would seem to refer more to the parent object and without an idea of
the internal workings one doesn't necessarily know that it is valid
in the place of [info ns]. Ie. [info ns] would give the namespace where
the object was defined in. Actually this would work for child objects
as well. Then the result would differ from [info parent]. Would
that make sense?

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

[Xotcl] XOTcl 1.6.5 available

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Fri, 13 Nov 2009 21:33:33 +0100

Announcing XOTcl 1.6.5
*************************

Dear XOTcl Community,

Friday 13th sounds like a good day for a release!

We are pleased to announce the availability of XOTcl 1.6.5,
which is contains mostly bug fixes

Major changes relative to 1.6.4 are:

     * fixed namespace visibilty problem reported by
       Mykhaylo Sorochan

     * fixed var resolver/memory leak problem reported by
       Victor Mayevski (when XOTcl is compiled against
       Tcl 8.4.*, but loaded into 8.5.*)

For more details about the changes, please consult the
ChangeLog and documentation. The planned next release
will be 2.0.0

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

best regards
-gustaf neumann

[Xotcl] Re: [Xotcl] Using source with the xodoc tool / Debian

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: <uwe.zdun_at_uni-essen.de>
Date: Tue, 19 Dec 2000 17:47:15 +0100 (CET)

>>>>> "KL" == Kristoffer Lawson <setok_at_fishpool.com> writes:

KL> I haven't yet got round to upgrading to 0.83 and the upgraded xodoc tool,
KL> but I'd like to know how it reacts to splitting up a package into several
KL> files? Ie. I have one large file with lots of classes but to structure
KL> it more neatly I am moving parts of it into other files with the same
KL> package name so that "package require" gets all of them. Will this affect
KL> the operation of xodoc? Specifically I'd like to know what happens
KL> when using the "_at_ File" system as I'd probably like to document each
KL> file separately like that.

xodoc works at the moment per file. I.e. when documenting several
files with the same package provides/requires it will produce a html
doc file for each (in this file the "_at_ File" is evaluated). But is
this the behavior you intend?

we could also merge components that are split across files into one
documentation file. I'm not sure which solution is the best one ...
what do you think?

KL> In addition all the classes in the different files are evaled into the
KL> same namespace, so xodoc should handle this too.

I think this works ... but only with several doc files.

KL> On another issue we have made Debian packages of XOTcl (0.82, but 0.83 is
KL> on the way) if someone is interested.. They're not extensively tested but
KL> they seem to work on the machines here. Probably candidates for merging
KL> into the official Debian system at some later time.

great! if you like to maintain Debian packages & have a web page for
them, we can link this page with the XOTcl download page?

--Uwe

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_xotcl.org, uwe.zdun_at_uni-essen.de

Re: [Xotcl] Checking to see if a class is defined

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Adam Turoff <adam.turoff_at_gmail.com>
Date: Fri, 25 Jun 2004 11:11:23 -0400

On Fri, 25 Jun 2004 16:19:16 +0200, Uwe Zdun <uwe.zdun_at_wu-wien.ac.at> wrote:
> % Object isobject MyClass
> 0
> % Class create MyClass
> ::MyClass
> % Object isobject MyClass
> 1
> % MyClass isclass
> 1

Works great. Thanks.

-- Adam

Re: [Xotcl] info method behaviour

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sun, 12 Aug 2001 00:07:11 +0300 (EEST)

On Sat, 11 Aug 2001, Zoran Vasiljevic wrote:

>
> You can do this pretty easy with:
>
> % [ob info class] info instprocs
>
> ... and similar.

That is what I do, but required me to know that a proc is inherited
from somewhere! I have both types, procs and instprocs (which are both
callable from the object) and I would like to be able to ask information
about them without knowing where they're from.
>
> AFAIK, the "ob info procs|args|body" is ment to be used
> with per-object resources (procs), like for example:

Yes, that what it appears to do, but as such it's limited. I would like
a uniform way of asking information about inherited procs and per-instance
procs. In fact I might even say that to separate those on this level is
confusing the object model.

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

Re: [Xotcl] Incorrect behavior?

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Wed, 29 Jun 2011 12:32:04 +0200

Victor,

> %Object create o
> ::o
> %o attribute {a oldvalue}
> ::o::a
> %o a
> oldvalue
> %o attribute {a newvalue}
> ::o::a
> %o a
> oldvalue

Incorrect behavior? Not quite, but probably behaviour not that
"accessible" at first sight :)

In line 5, by accessing a, the default value "oldvalue" is assigned to
am object variable a owned by ::o. In line 7, by providing a new default
value, you do not change the state of ::o (the value assignment of the
var a), rather you modify a property of the attribute slot a.

So, in line 9, given that an object variable a already exists, the slot
machinery does not (re-)assign the default value. You would have to
clear ::o's state first:

::o eval {unset :a}

and then do:

o attribute {a newvalue}
o a

Note that currently, for per-object attributes only, the unset *must*
happen before the re-definition of the attribute slot and its default.
There might be ways to relax this restriction at some point ...

//stefan

Re: [Xotcl] XOTcl 2 problem

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Sun, 10 Jun 2012 11:54:01 +0200

|XOTcl2 is fine, just the example on http://next-scripting.org/xowiki/getstart was wrong.
Instead of

% Greeter create g -parameter|| Anna|

it should read:

|% Greeter create g -||name|| Anna|

Greeter does not have a parameter named "parameter", but
a parameter "name".

Many thanks for reporting the problem back!

All the best
-gustaf neumann


On 09.06.12 10:00, Kulcsár Ferenc wrote:
> Dear list,
>
> I'm playing with the example codes placed here: http://next-scripting.org/xowiki/getstart but the XOTcl example isn't working as expected.
> I have the following error:
>
> ./tclsh8.5 proba1.tcl
> ::g: unable to dispatch method 'parameter' during '::g.parameter'
> ::g ::xotcl::Object->residualargs
> ::Greeter ::xotcl::Class->create
> invoked from within
> "Greeter create g -parameter Anna"
> (file "proba1.tcl" line 13)
>
> the code in the proba1.tcl file is:
>
> package require XOTcl
>
> xotcl::Class create Greeter -parameter name
> Greeter instproc say_hello {} {
> my instvar name
> puts "Welcome $name!"
> }
> Greeter instproc say_bye {} {
> my instvar name
> puts "Goodbye $name!"
> }
>
> Greeter create g -parameter Anna
>
> g say_hello
>
> The nx version is working well.
>
> Any hints are appreciated.
>
> TIA,
>
> feri
>
> P.s.: The nsf2.0b3 and git versions display the same error.
>

[Xotcl] two procs (-proc) for Attribute

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Mykhaylo Sorochan <msorc_at_bigmir.net>
Date: Mon, 20 Jul 2009 00:27:54 +0300

Hello,

How to define several procs for one Attribute in class definition?
Particularly, I want to define both assign and get procs at once.

-- 
Regards,
Mykhaylo Sorochan

Next Page