[vwnc] Creating variables

I have a question regarding the creation of variables. My end-users will create a healthy amount of
variables (it's a modeling environment) so it's crucial to simplify this task. So instead of saying
for example

stage_1 := Stage new.
stage_2 := Stage new.
...
stage_n := Stage new,

I actually want them (and me) to use something like

1 to: 100 do: [ :i | stage_i := Stage new]

which won't work, as far as I know. I browsed the system but couldn't come up with something
convincing. Best I found was

1 to: 100 do: [ :i | VariableBinding
                        key: ('stage_' , i printString) asSymbol
                        value: Stage new]

but I might be miles off. I'm highly grateful for any pointers, thanks a lot!

Mike

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hello,

Can somebody direct me to the place where VW namespaces can be reserved?

Thanks.

Ivan

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

http://www.cincomsmalltalk.com/CincomSmalltalkWiki/VW+NameSpace+Reservat
ions

... but one should keep in mind that thislist is not and cannot be
enforced in any way by any one AFAICT.

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Ivan Tomek
Sent: Tuesday, June 23, 2009 12:43 PM
To: [hidden email]
Subject: [vwnc] Reserved top-level name spaces

Hello,

Can somebody direct me to the place where VW namespaces can be reserved?

Thanks.

Ivan

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Jun 23, 2009, at 12:54 PM, Boris Popov wrote:

> http://www.cincomsmalltalk.com/CincomSmalltalkWiki/VW+NameSpace+Reservat
> ions
>
> ... but one should keep in mind that thislist is not and cannot be
> enforced in any way by any one AFAICT.

I won't pretend to speak for anyone but myself on this issue. My  
opinion personally is to have at most 1 namespace and tie it to your  
project. We don't derive much value from the fact that we have all of  
the Browser stuff buried in a Refactory namespace. If I had placed the  
Cairo stuff in a KeyTech namespace, or a TravisGriggs namespace or a  
Cincom namespace, all of them would be obsolete placement at one point.

--
Travis Griggs
Objologist
My Other Machine runs OSX. But then... so does this one.



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I understand. Are these variables instance variables? Perhaps you can use  
a helper method like:

(1 to: 100) do: [
                self
                        compile:
                                "varSet
                                stage_" , i printString ," := Stage new";
                        perform: #varSet.]

Unfortunately this is neither fast nor beautiful.

Steffen


Am 23.06.2009, 21:12 Uhr, schrieb Mike Bielser <[hidden email]>:


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi Mike,

I have read the other replies and your responses.   Having built several
simulation environments in the past, I think I understand your requirement.

That said,   I still think the notion of using a Dictionary is better
than the notion of trying to create Smalltalk instance variables on the
fly.    You can create the "variable name" as you said, mathematically,
as a string;   use that string as a key into the Dictionary;  and store
a full-up Stage object as the value at each key.

This may seem inefficient,  but it is very flexible, and the Dictionary
lookups are hashed anyway and quite optimised.

This is a better and simpler means to achieve flexibility in your
simulation environment than any attempt to compile the new variable
names on the fly.

Regards.

Gregory Bourassa



Mike Bielser wrote:

-----------------------------------------
Key Technology, Inc. Disclaimer Notice - The information and
attachment(s) contained in this communication are intended for the
addressee only, and may be confidential and/or legally privileged.
If you have received this communication in error, please contact
the sender immediately, and delete this communication from any
computer or network system. Any interception, review, printing,
copying, re-transmission, dissemination, or other use of, or taking
of any action upon this information by persons or entities other
than the intended recipient is strictly prohibited by law and may
subject them to criminal or civil liability. Key Technology, Inc.
is not liable for the improper and/or incomplete transmission of
the information contained in this communication or for any delay in
its receipt.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Mike Bielser wrote:
This might be a good place to use a Dictionary, something like:

   myStageDict := Dictionary new.
   1 to: 100 do: [:i | myStageDict at: ('stage_' , i printString)
                                   put: Stage new].

Regards,

-Martin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Dear Steffen, Gregory and Martin
thanks a lot for your replies! Steffen's (second!) code snippet is closest to what I've been
"fantasizing" ;)

I'm aware that I can use a dictionary (well, actually almost any collection object, depending on how
I implement the details of Stage), I just don't like "being forced" to use one.

 From a purist point of view (sorry, I work in research; math actually, "déformation professionelle"
as the French say) I don't need one, so why use one? Instead of n objects I've got n+1 objects AND
an additional layer... not to mention that some of the objects/functionality might get exposed to
the end-user later (think "scripting" or API) and they're bound to ask the same questions I did.

I just expected to find some language support for "on the fly" variable creation. So, from my point
of view, there's room to improve Smalltalk (at least the VW dialect of Smalltalk).

That said, I probably WILL use a dictionary, but VERY reluctantly...

Thanks again all you guys

Mike

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

If you want to define the variables as instance variables you can do
something like:
obj := MyClass new.
1 to: 100 do: [:i |
     | var |
     var := 'ivar_', i printString.
     obj class addInstVarName: var.
     obj instVarNamed: var put: Stage new].
obj

But if you want to define the variables as local variables you can
define a new method by doing something like:
stream :=  String new writeStream.
stream nextPutAll: 'newMethod'; cr.
vars := OrderedCollection new.
1 to: 100 do: [:i |
     vars add: 'stage_', i printString].
stream tab: 1; nextPutAll: '| '.
vars do: [:varName |
     stream nextPutAll: varName; nextPut: Character space.
].
stream nextPutAll: '|'; cr.
vars do: [:varName |
     stream tab: 1; nextPutAll: varName; nextPutAll: ' := Stage new.'; cr.
].
obj class compile: stream contents classified: #accessing

In both cases it is easy to add convenient methods that generates the
code, e.g. in the class Class or its superclasses.
I have done similar code generation several times for instance when I
wanted to automatically generate (working) skeletons of MVC triads, when
I played with making my own components in Pollock/Widgetry or simply
when I before the RB Browser wanted to generate accessor methods to
instance variables.

Cheers,
Björn

On 2009-06-23 19:45, Mike Bielser wrote: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Mike,

I think the key question we need to ask first is how will the variables be accessed?  You said this is part of a modeling environment.  So, are these instance attributes of an object, shared attributes of an object class, or common attributes shared among classes?  Do you want the object hierarchy to be extended with accessors and mutators for the variables?  The code to define these will depend on those answers.

VW does provide on-the-fly variable creation:  you can add or remove any instance variable of a class, you can define class shared variables, or you can add variables into a name space.  You can treat the class pool or global name space as a dictionary or you can use the system definition methods to make sure the changes are logged into the change set.

Instance variables are handy if you can limit the total number of them that would be defined for a single class.  I don't recall if the limit has been increased from 255.  Dictionaries have no such limitation.  I've written a dynamically extensible database interface which allows you to define new or change old classes, attributes, and relations.  Instance variables tied me too heavily to structure and (under older versions of VW) were expensive.  Dictionaries don't suffer from any related problems although they're a bit slower.  It all depends on the requirements...

Cheers!
 
Tom Hawker
--------------------------
Senior Framework Developer
--------------------------
Home +1 (408) 274-4128
Office +1 (408) 576-6591
Mobile +1 (408) 835-3643
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Björn Eiderbäck
Sent: Tuesday, June 23, 2009 3:23 PM
To: Mike Bielser
Cc: [hidden email]
Subject: Re: [vwnc] Creating variables

If you want to define the variables as instance variables you can do
something like:
obj := MyClass new.
1 to: 100 do: [:i |
     | var |
     var := 'ivar_', i printString.
     obj class addInstVarName: var.
     obj instVarNamed: var put: Stage new].
obj

But if you want to define the variables as local variables you can
define a new method by doing something like:
stream :=  String new writeStream.
stream nextPutAll: 'newMethod'; cr.
vars := OrderedCollection new.
1 to: 100 do: [:i |
     vars add: 'stage_', i printString].
stream tab: 1; nextPutAll: '| '.
vars do: [:varName |
     stream nextPutAll: varName; nextPut: Character space.
].
stream nextPutAll: '|'; cr.
vars do: [:varName |
     stream tab: 1; nextPutAll: varName; nextPutAll: ' := Stage new.'; cr.
].
obj class compile: stream contents classified: #accessing

In both cases it is easy to add convenient methods that generates the
code, e.g. in the class Class or its superclasses.
I have done similar code generation several times for instance when I
wanted to automatically generate (working) skeletons of MVC triads, when
I played with making my own components in Pollock/Widgetry or simply
when I before the RB Browser wanted to generate accessor methods to
instance variables.

Cheers,
Björn

On 2009-06-23 19:45, Mike Bielser wrote: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I'm not sure how you plan to let your users browse created classes, but
Travis described (and implemented) a rather neat concept for adding
instance variables some time ago in these blogposts:

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=What_is_there_to_a_name&entry=3373674497
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Slots_all_the_Way_Down&entry=3373903413
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Managing_Instance_Variables_Methodically&entry=3376826809

Cheers,
Henry

On 23.06.2009 19:45, Mike Bielser wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

According to ImplementationLimits7x.pdf,

Named instance variables - 4096 per class
Method variables - 255
Block variables - 255

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, June 23, 2009 3:41 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [vwnc] Creating variables

Mike,

I think the key question we need to ask first is how will the variables be accessed?  You said this is part of a modeling environment.  So, are these instance attributes of an object, shared attributes of an object class, or common attributes shared among classes?  Do you want the object hierarchy to be extended with accessors and mutators for the variables?  The code to define these will depend on those answers.

VW does provide on-the-fly variable creation:  you can add or remove any instance variable of a class, you can define class shared variables, or you can add variables into a name space.  You can treat the class pool or global name space as a dictionary or you can use the system definition methods to make sure the changes are logged into the change set.

Instance variables are handy if you can limit the total number of them that would be defined for a single class.  I don't recall if the limit has been increased from 255.  Dictionaries have no such limitation.  I've written a dynamically extensible database interface which allows you to define new or change old classes, attributes, and relations.  Instance variables tied me too heavily to structure and (under older versions of VW) were expensive.  Dictionaries don't suffer from any related problems although they're a bit slower.  It all depends on the requirements...

Cheers!
 
Tom Hawker
--------------------------
Senior Framework Developer
--------------------------
Home +1 (408) 274-4128
Office +1 (408) 576-6591
Mobile +1 (408) 835-3643
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Björn Eiderbäck
Sent: Tuesday, June 23, 2009 3:23 PM
To: Mike Bielser
Cc: [hidden email]
Subject: Re: [vwnc] Creating variables

If you want to define the variables as instance variables you can do
something like:
obj := MyClass new.
1 to: 100 do: [:i |
     | var |
     var := 'ivar_', i printString.
     obj class addInstVarName: var.
     obj instVarNamed: var put: Stage new].
obj

But if you want to define the variables as local variables you can
define a new method by doing something like:
stream :=  String new writeStream.
stream nextPutAll: 'newMethod'; cr.
vars := OrderedCollection new.
1 to: 100 do: [:i |
     vars add: 'stage_', i printString].
stream tab: 1; nextPutAll: '| '.
vars do: [:varName |
     stream nextPutAll: varName; nextPut: Character space.
].
stream nextPutAll: '|'; cr.
vars do: [:varName |
     stream tab: 1; nextPutAll: varName; nextPutAll: ' := Stage new.'; cr.
].
obj class compile: stream contents classified: #accessing

In both cases it is easy to add convenient methods that generates the
code, e.g. in the class Class or its superclasses.
I have done similar code generation several times for instance when I
wanted to automatically generate (working) skeletons of MVC triads, when
I played with making my own components in Pollock/Widgetry or simply
when I before the RB Browser wanted to generate accessor methods to
instance variables.

Cheers,
Björn

On 2009-06-23 19:45, Mike Bielser wrote: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 24.6.2009 0:22 Uhr, Björn Eiderbäck wrote:
As far as I've understood your code examples (and I might have misunderstood them), neither of the
two apply to my situation...

Mike

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 24.6.2009 0:49 Uhr, Henrik Sperre Johansen wrote:
Thanks a lot for these pointers! I'll take a look at them right away...

Mike

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 24.6.2009 0:40 Uhr, [hidden email] wrote:
According to what Boris Popov just posted, named instance variables would work as far as the limit
(=4096) is concerned. To make a (very) long story short (too short to appreciate the intricacies):
"model instance" = "(abstract) model" + "(instance) data". Depending on the "(abstract) model" type,
there will be stages or not.
So yes, stage(s) can be viewed as instance variables of the abstract model. But as Gregory said, I
could take a dictionary, add the stages to the dictionary and add the dictionary to the abstract
model as well...
Since stages are not the only abstract model entities this is probably smarter; otherwise I'll
sooner or later hit the ceiling (=4096 instance variables)

Mike

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Mike,

Hmm.  I thought you were describing a wish which is almost exactly fulfilled by Bjorn's first example.

What _do_ you mean when you say "variable"?

Gregory


Mike Bielser wrote:

On 24.6.2009 0:22 Uhr, Björn Eiderbäck wrote:
  

If you want to define the variables as instance variables you can do 
something like:
obj := MyClass new.
1 to: 100 do: [:i |
     | var |
     var := 'ivar_', i printString.
     obj class addInstVarName: var.
     obj instVarNamed: var put: Stage new].
obj

But if you want to define the variables as local variables you can 
define a new method by doing something like:
stream :=  String new writeStream.
stream nextPutAll: 'newMethod'; cr.
vars := OrderedCollection new.
1 to: 100 do: [:i |
     vars add: 'stage_', i printString].
stream tab: 1; nextPutAll: '| '.
vars do: [:varName |
     stream nextPutAll: varName; nextPut: Character space.
].
stream nextPutAll: '|'; cr.
vars do: [:varName |
     stream tab: 1; nextPutAll: varName; nextPutAll: ' := Stage new.'; cr.
].
obj class compile: stream contents classified: #accessing

In both cases it is easy to add convenient methods that generates the 
code, e.g. in the class Class or its superclasses.
I have done similar code generation several times for instance when I 
wanted to automatically generate (working) skeletons of MVC triads, when 
I played with making my own components in Pollock/Widgetry or simply 
when I before the RB Browser wanted to generate accessor methods to 
instance variables.

Cheers,
Björn
    

As far as I've understood your code examples (and I might have misunderstood them), neither of the 
two apply to my situation...

Mike

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

  

Key Technology, Inc. Disclaimer Notice - The information and attachment(s) contained in this communication are intended for the addressee only, and may be confidential and/or legally privileged. If you have received this communication in error, please contact the sender immediately, and delete this communication from any computer or network system. Any interception, review, printing, copying, re-transmission, dissemination, or other use of, or taking of any action upon this information by persons or entities other than the intended recipient is strictly prohibited by law and may subject them to criminal or civil liability. Key Technology,  Inc. is not liable for the improper and/or incomplete transmission of the information contained in this communication or for any delay in its receipt.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Mike,

That answers my previous question too.  :-)

Gregory

Mike Bielser wrote:

-----------------------------------------
Key Technology, Inc. Disclaimer Notice - The information and
attachment(s) contained in this communication are intended for the
addressee only, and may be confidential and/or legally privileged.
If you have received this communication in error, please contact
the sender immediately, and delete this communication from any
computer or network system. Any interception, review, printing,
copying, re-transmission, dissemination, or other use of, or taking
of any action upon this information by persons or entities other
than the intended recipient is strictly prohibited by law and may
subject them to criminal or civil liability. Key Technology, Inc.
is not liable for the improper and/or incomplete transmission of
the information contained in this communication or for any delay in
its receipt.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 24.6.2009 1:14 Uhr, Gregory Bourassa wrote:
> Mike,
>
> Hmm.  I thought you were describing a wish which is almost exactly
> fulfilled by Bjorn's first example.

Yes and no :)

If you take Björn's "MyClass" to be my "abstract model": Yes, I can add them that way.

However, thogether with all the other abstract model entities (like parameters, restrictions,
objectives,...) I'll run against the inst var ceiling of 4096... so no.

> What _do_ you mean when you say "variable"?
>
> Gregory

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thanks to all.

Ivan

Quoting Travis Griggs <[hidden email]>:



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc