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

Weblog Page

Showing 621 - 630 of 1561 Postings (summary)

Re: [Xotcl] Static member functions?

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

From: Neophytos Demetriou <k2pts_at_cytanet.com.cy>
Date: Thu, 17 Apr 2003 00:28:14 +0300

>
>
>can't read "x": no such variable
>
>I'm using XOTcl 1.0.2 (compiled from source) & Tcl 8.4.2 (.deb) on Linux.
>
>

I had the same issue when I was experimenting with binding sql results
into different variable names using traces. However, I haven't checked
it out further but I suppose it could be handled by the unknown mechanism.

>(Neophytos: yes, I am the author of nstcl fame, though I didn't realize
>that would make me famous anywhere. :-)
>
:) Still it is nice to see that you are considering xotcl ...

Best wishes,
Neophytos

RE: [Xotcl] Filters on classes

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

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Mon, 15 Nov 2004 10:56:17 -0500

One other thought... have you tried explicitly namespace scoping your object... I know that there were some namespace issues with the early 1.3 series.

try:
 TestA ::a
 ::a x 1

> -----Original Message-----
> From: xotcl-bounces_at_alice.wu-wien.ac.at
> [mailto:xotcl-bounces_at_alice.wu-wien.ac.at]On Behalf Of
> MichaelL_at_frogware.com
> Sent: Monday, November 15, 2004 10:33 AM
> To: xotcl_at_alice.wu-wien.ac.at
> Subject: [Xotcl] Filters on classes
>
>
> I'm using XOTcl 1.3.1.
>
> This code:
>
> Object instproc someFilter {args} {
> puts "self class = [self class]"
> puts "self called class = [self calledclass]"
> puts "self = [self]"
> puts "self calledproc = [self calledproc]"
> puts "args = $args"
> puts ""
> next
> }
>
> Class TestA -parameter {{x 0}}
> TestA filter someFilter
>
> TestA a
> a x
> a x 10
>
> produces this output:
>
> self class = ::xotcl::Object
> self called class =
> self = ::TestA
> self calledproc = a
> args =
>
> self class = ::xotcl::Object
> self called class = ::xotcl::Class
> self = ::TestA
> self calledproc = unknown
> args = a
>
> self class = ::xotcl::Object
> self called class = ::xotcl::Class
> self = ::TestA
> self calledproc = create
> args = a
>
> self class = ::xotcl::Object
> self called class = ::xotcl::Class
> self = ::TestA
> self calledproc = alloc
> args = a
>
> invalid command name "a"
>
> Note that filtering on "TestA a" seems to prevent the
> creation of an obj
> named "a". Any ideas?
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

Re: [Xotcl] Precedence Order

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

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Wed, 30 Aug 2006 10:01:16 -0600

Uwe Zdun <uwe.zdun_at_wu-wien.ac.at> wrote on 08/29/2006 12:20:16 PM:

> well, why do you think the behavior breaks encapsulation?

When I extend Base with BaseMixin, I'm altering the interface to Base. I
can't safely alter the interface to Derived, because Base and BaseMixin
don't necessarily know about Derived. In fact, since Derived is
completely independent, it might not even exist when BaseMixin is defined.
In gerneral BaseMixin can't be defined to work correctly with all possible
derived classes, that set is open.

I believe when I add a mixin to Base I'm intercepting Base method
invocations. When Derived invokes "next", it's logically chaining to Base.
The Base may or may not have BaseMixin, but Derived shouldn't need to
know. With BaseMixin intecepting Derived methods, BaseMixin needs to be
made to work with Base & Derived. In practice, this seems like you can't
safely use a mixin on any class thats also used as a superclass since the
mixin will intercept any derived class's interface.

In practice, it's not possible to work with both. Assume BaseMixin is
intercepting a leaf method with a leaf method: if BaseMixin invokes 'next'
it will break Base and if it doesn't invoke 'next' it will break Derived.

The current behavior means I can't intercept a subset of the hierarchy, I
have to intercept the whole thing. That means I can't encapsulate the use
of a mixin; the mixin gets applied globally.


> Rather a
> behavior where mixin are not added in precedence before the class
> hierarchy, requires you to know about the interceptor and might break
> encapsulation. Consider you are omitting to use "next" in a method of
> Derived, for instance simply because this method exists nowhere else in
> the class hierarchy. If the mixin would be introduced after Derived, you

> would need to modify Derived to introduce a method of the same name on
> the mixin. If the mixin is always before the class hierarchy, as a base
> hierarchy developer you don't need to care for how a potential mixin is
> designed, because you can be sure once a call has reached your class,
> you can be sure, you cannot accidently introduce side-effects on mixins
> (maybe designed later by other developers).

To be clear, I agree that a mixin should take precedence over the class
it's mixed into. I don't think it should take precedence over classes
derived from the class it's mixed into. If I wanted to intercept method
invocations on Derived, I would add a mixin to Derived but my explicit
semantic is that I want to intercept methods on Base.



To ground this discussion a bit more in reality, my base class accesses
hardware (Device). I then have a AppDevice class derived from the Device
class that I use in my application. AppDevice will get a method, perform
some processing and then invoke Device (via 'next').

So from the app point of view I have:
AppDevice --> Device

For testing purposes I want to use a simulator. I created a DeviceSim
class that reads and writes a buffer instead of the HW. I don't want my
derived classes to know or care if it's using the simulator or the actual
device. In either case the classes define leaf methods; the methods don't
(and can't) chain.

In the test environment I want DeviceSim to intercept Device methods
("Device mixin add DeviceSim"):
AppDevice --> DeviceSim --> Device

But what I get is:
DeviceSim --> AppDevice --> Device

Since both Device and DeviceSim have leaf methods, adding DeviceSim as
mixin to Device breaks AppDevice. It's the documented behavior, but it
doesn't feel like the right behavior. The behavior I wanted (and what my
code expressed) was to intercept Device methods not AppDevice methods. I
don't see any way to limit interception to the subset of the hierarchy
that I want.

Is what I'm trying to do unreasonable? It feels like I'm using the
language features as intended, I just don't get the desired result.

[Xotcl] Re: XOTcl is great!!

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 7 Sep 2005 15:18:09 +0300

On 7 Sep 2005, at 14:23, Taral wrote:

> I was wondering about whom I'm talking to. You guys are obviously
> from Germany/Austria based on my guess from your email address. It
> would be nice to know you guys little more to help the
> communication. Do you guys have any personal webpage? I don't have
> one myself :( But now I feel like I should have one. So I will
> try to put up one sometime soon.

I'm not sure if you were asking me too. I myself am not a core XOTcl
developer -- that's Uwe and Gustaf. However, I do have an interest in
seeing it develop and particular become as stable and mature a
platform as possible. I quite often find myself starting a project,
thinking it so simple that I'll do it in pure Tcl. However, it almost
always expands enough that I find that simply doing that "package
require XOTcl" makes everything clearer. Especially now as XOTcl is
included in OS X.

If you're interested, I live in Helsinki Finland and if you're ever
around these parts, feel free to give us a ring and we can go out for
a pint :-) (Goes for everyone else on the list too).

As for a personal webpage, my signature has it all :-)

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

[Xotcl] Workaround for "value of parameter could be non-positional argument"

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

From: Arthur Schreiber <schreiber.arthur_at_googlemail.com>
Date: Thu, 21 Jun 2012 10:22:37 +0200

Hello Gustaf,

what is the recommended way to work around the warning that is put out by
code like this:

nx::Class create Test {
    :property value:required
}

set value "-h"
Test new -value $value
# => Warning: value '-h' of parameter '-expected' could be a non-positional
argument during:
# ::nsf::__#0l configure -expected -h


Kind regards,
Arthur

[Xotcl] info instances for mixins

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

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Fri, 15 Jul 2005 14:58:28 -0400

Hi,

I am looking for functionality similar to Class info instances for mixins
and instmixins.

Essentially I'd like:

>xotclsh
% Class A
::A
% A a
::a
% A info instances
::a
% Class B
::B
% A instmixin B
% B info instances

This last line to return.
::a

Is this possible with any info proc that exists today or could something
like this be easily added to the
code?

I am trying to simplify searches on a large object graph by using mixins. I
already use introspection to find instances of certain classes. I would like
to be able to do the same with mixin classes. Is the mixin functionality
implemented with object->class pointers. Are there pointers mixin->object or
mixin->class->object?

Thanks,

Ben

Re: [Xotcl] constructor initialization problem

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

From: jim <j_marvin_at_localnet.com>
Date: Tue, 9 Dec 2003 10:04:32 -0500

>>Hi marvin,
>>in order to get an instance variable into the scope of an instproc,
you have to import it via the method instvar


thanks Gustaf!

I think I'll try another program out and learn some more. I have 3 more
of these easier funny object oriented
programs we were given in intro to C++ class. I am new to both tcl/tk
and xotcl so it should be a challenge
translating them.

later
marvin

Re: [Xotcl] Issue with mixin delete

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 09 May 2006 19:15:22 +0200

Scott Gargash schrieb:
>
> > We have to deal with the following cases when we have e.g. a precedence
> > order M1 M2 M3 M4, and the following happens in the BEFORE part of M2:
> >
> > a chain is set to: M1 M3 M4 (your case, you want to continue
> with M3)
> > b chain is set to: M1 M4 defensible M4
> > c chain is set to: M2 M1 M3 M4 under current semantics,
> continue with M1
> > d chain is set to: M4 M2 M3 M1 continue with M3, M4 will never by
> > invoked
>
> Yup, that's exactly the behavior I (naively) had expected.
>
> But to be clear, what is the current behavior of 'next' for each of
> these cases? To unwind the call stack? When can the updated mixin
> list be considered to have taken effect?
>
the current implementation the mixin command is an immediate update (it
replaces the old mixin chain), "next" searches for the current class
(M2), but does not find it, and assumes that it is at the end of the
mixin chain.
>
> > The most promissing approach not mentioned yet is to develop a
> > c-level implementation of mixin/instmixin/filter/instfilter delete,
> > which simply flags the entry in the chain as deleted.....
>
> Interestingly, that's how I assumed it was implemented, which is
> probably why I was surprised.
>
i will check this option out in more detail (earliest this weekend). so,
don't hold your breath...

-gustaf

Re: Oops (was Re: [Xotcl] Bug: make install step tries to perform chmod on xowish even if not configured to build [PATCH])

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 10 Apr 2004 21:48:09 +0200

On Friday 09 April 2004 02:20, Jim Lynch wrote:
> > Hi,
> >
> > I got an error when building xotcl without tk and wish support where it
> > tries to do a chmod on xowish (which of course doesn't exist at that
> > point.)
> >
> > This patch will fix the problem
>
> Actually no it won't, it's broke... needs " ; \ " at the line ends of the
> new chmod lines. Here's a better patch (attached).

 Hi Jim,

 i get the impression you are fixing things that are not broken
 in the general distribution. The configure stuff is
 defined to produces always a file xotclsh or xowish, no
 matter whether you compile with or without --with-xotclsh.
 Sounds wierd, isn't it? If you compile with the default
 values (without xotclsh), the generated file
 unix/xotclsh is a small tcl script with e.g. the following content:

#!/usr/bin/tclsh8.4
if {$argc == 0} {
  puts "Don't use [info script] as interactive shell! Use instead:"
  puts " /usr/bin/tclsh8.4"
  puts " package require XOTcl; namespace import ::xotcl::*"
} else {
  package require XOTcl
  namespace import ::xotcl::*
  set argv0 [lindex $argv 0]
  set argv [lreplace $argv 0 0]
  incr argc -1
  source $argv0
}
 This scriped is generated from xotclsh.in and requires a "chmod +x".

 If you configure ... --with-xotclsh, the file unix/xotclsh is a true
 binary (a statically linked shell, also useful for these few platforms
 that have still problems with dynamic loading).

 Producing a shell in form of a tcl script is useful for
 legacy applications, that still use xotclsh to call the xotcl scripts.

-gustaf

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

[Xotcl] Filter Problem - Help!

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

From: Sheik Yussuff <sheik_at_carib-link.net>
Date: Tue, 7 Aug 2001 22:51:22 -0300

Below is sample code to illustrate a problem I
am having with filters.
1. Object a is sent the message mb(not an instproc) of A
2. Filter af of object a intercepts and
   dispatches method mbb to object b
3. Filter bf of object b intercepts and
   redispatches method maa to object a
4. This time the filter af does not intercept method maa!!
   The method maa is sent directly to object a with
   the resulting error: object a unable to dispatch
   method maa.

Can anyone assist me in explaining what is happening here?
------------------------------------------------------------
#Code: Win 95 version 0.85

Class A -parameter {delegate}

A instproc af args {
  set method [self calledproc]
  if {[[self] exists delegate]} {
    set del [[self] set delegate]
    if {$method == "maa"} {
      return [eval $del mbb]
    }
    if {$method != "ma"} {
      return [eval $del $method $args]
    }
  }
  next
}

A filter {af}

A instproc ma args {
  puts "method ma of A"
}


Class B
B instproc bf args {
  set sender [self callingobject]
  set method [self calledproc]
  puts "method is: $method"
  if {$method == "mb"} {
    
    return [eval $sender maa]
  }
  next
}

B filter bf

B instproc mb args {
  puts "method mb of B"
}

B instproc mbb args {
  puts "method mbb of B"
}

#Test case
B b
A a
a delegate b
#a ma
a mb

Next Page