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

Weblog Page

Showing 1191 - 1200 of 1561 Postings (summary)

Re: [Xotcl] non positional argument

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: Wed, 27 Oct 2010 08:53:26 +0200

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] Real ZOO web site, welcome! <{rwfoCzl1zx0zlhq1df1dw>

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

From: Arcady 29357 <MAILER-DAEMON30726_at_chat.ru>
Date: Sun, 30 Jun 2002 16:33:18 +0400
I got your email from ICQ, may be it will be interested?
The BEST zoo site on the _at_net!
Sex With Dogs
Horse Blow Jobs.
Snake Fuck.
REAL ANIMAL FUCKING!
100% HARDCORE!
rol.rape-sexy.com

unsub
Good luck.

Re: [Xotcl] Bug when changing class

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, 8 Feb 2005 19:51:26 +0200

On Feb 8, 2005, at 2:25 PM, Gustaf Neumann wrote:
>
> Providing means to make "obj class Class" and "cl class Object"
> working is certainly
> doable, but i am not sure that is worth the effort, since one can
> achieve similar effects
> already from the tcl level (see below).

OK, well as this was about academic interest than anything else, I'll
just let you guys decide what's best.

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

[Xotcl] new feature idea

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

From: <vitick_at_gmail.com>
Date: Wed, 29 Sep 2010 11:28:16 -0700 (PDT)

It occurred to me that XOTcl could benefit or it's "coolness" value could be raised even more if it had method chaining similar to JQuery. Example:

Class create Myclass

Myclass :method a args {
   process {*}$args;
}

Myclass :method b args {
   process {*}$args;
}


Myclass create myobj

execute:

myobj :chain :a :b {value1 value2}

or:

myobj :chain :a :b :a :b :destroy {value1 value2}

################
syntax:

obj :chain :method1 :method2 .... {arg1 arg2 ...}

################
functionality:

each method would be executed in the order listed with the args provided in the end of the "chain" method.
################

This functionality is even more enhanced with mixins and superclasses where each chained method would be passed to a mixin/superclass via [next].


P.S. this is not really a feature request at the moment because I see you are very busy doing a lot of work on Next. And that has more priority. Also, the "chain" functionality can be easily done via scripting it myself. Again, for the "coolness" or "extra power" value, it would be nice to have that, in my opinion, as a built-in feature.

XOTcl/NX mailing list by object move?

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, 19 Mar 2006 15:24:01 +0200

On 19 Mar 2006, at 14:49, Scott Gargash wrote:
>
> Snit has a "myvar" method that returns the fully qualified name of
> a snit member variable. Perhaps something similiar (a method that
> returned a "reference" to an instance variable) would be useful in
> XOTcl?
Yes, quite possibly, but of course then you need some namespace
logic, at least internally. Still, it sounds like, whatever the
implementation, that might be a good addition to XOTcl as it hides
the implementation details.

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

Re: [Xotcl] [Fwd: XOTcl and debian testing..]

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Thu, 23 Sep 2004 16:44:34 +0300 (EEST)

On Thu, 23 Sep 2004, Jim Lynch wrote:

> Debian dropped xotcl because its build system kept exhibiting problems,
> and because the maintainer knew only one or two users of xotcl.
>
> Hopefully, recent work done on that build system will make xotcl
> suitable for packaging again.

However, I doubt it would be Teemu who would do the packaging. He doesn't
use XOTcl himself. He was just involved with one project where that was
used.

Would be great if there was someone who could take that up in Debian (I'm
not familiar with making packages in Debian myself).

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

Re: [Xotcl] Weird behaviour

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: Thu, 05 Jan 2006 15:13:24 +0100

i am somewhat confused be the code (why are you creating and deleting
interpreters?)
is the following code doing, what you are trying? (aggregates rooms on
floors with a simple syntax)

-gustaf
===================================================
package require XOTcl
namespace import -force ::xotcl::*

namespace eval tih {
  Class Floor \
      -instproc has cmds {eval $cmds}
 
  Class Room -superclass Class \
      -parameter {{count 0} currTemp} \
      -instproc new args {
    set name "[self callingobject]::[namespace tail [self]]-[my incr count]"
    eval [self] create $name $args
      }

  Room room -parameter {{currTemp 300}}
  Room guestRoom -superclass room
  Room bathRoom -superclass room
  Room guestBathRoom -superclass bathRoom

  proc Celsius2Kelvin {a} { expr {$a+273.15} }

  Floor floor3 -has {
    guestRoom new
    guestBathRoom new -currTemp [Celsius2Kelvin 30]
  }

  puts "rooms on floor 3: [floor3 info children]"
  foreach c [floor3 info children] {
    puts "temperature in room $c is [$c currTemp]"
  }
 
}
exit
 

Re: [Xotcl] info method behaviour

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

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sun, 12 Aug 2001 11:29:14 +0200

On Saturday 11 August 2001 23:07, you wrote:
> 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.

I know this problem. The possible solution is to use procsearch function if
you know the name of method

set proc [$ob procsearch proc]

and ask the standard tcl info
if {$proc!=""} {
  info args $proc
}

To get all posible methods for some object in not so easy. I use something
like that in XOTclIDE

Class instproc getAllInstMethods {} {
    set methods [[self] info instprocs]
    foreach class [[self] info heritage] {
        set methods [concat $methods [$class info instprocs]]
    }
    return [lsort -unique $methods]
}

You also must look for all mixins classes and procs methods
$object info mixin

Object instproc allAvailableMethods {} {
     ::set method {}
     foreach class [concat [[self] info class] [[self] info mixin]] {
           ::set method [concat $method [$class getAllInstMethods]]
     }
     ::set method [concat $method [[self] info procs]]
     return [lsort -unique $method]
}

There are also class mixins (not implemented above).

happy hacking
Artur Trzewik

[Xotcl] xoRBAC - role based access control implemented in XOTcl

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: Thu, 8 Nov 2001 12:15:31 +0100

Dear XOTcl users,

you can find xoRBAC on the application page of http://www.xotcl.org. In
short, xoRBAC provides a Role-Based Access Control (RBAC) service that
conforms to level 4a of the NIST model for RBAC. It supports high-level
modeling of roles, permissions and constraints, and provides RDF
import/export for the access control data.

Details can be found in
http://wi.wu-wien.ac.at/home/mark/publications/ccs01.pdf

best regads
-gustaf

Re: [Xotcl] "tie" command

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

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Fri, 24 Jan 2003 10:46:16 +0100

On Friday 24 January 2003 04:32, Kristoffer Lawson wrote:
> Been thinking if this would make sense:
>
> while {$stuff} {
> tie myVar [MyClass new]
> ...
> }

Wait...

You know about:

  set myVar [MyClass new -volatile]

?

When the myVar goes out of scope, the destructor
is automatically called. It's been there since 0.9.4
or so, IIRC.

Cheers
Zoran

Next Page