User Command and Namespace

[PGilbert]

In the litterature it is mentionned that you can create a User Command with a Class. My question is: Can we create a User Command with a Namespace that has functions and variables only ? In my case I have some XAML that I don't want to type line by line in a Class, so I can't do easily a Class.

Thanks in advance

[DanB|Dyalog]

It is not necessary to use a class, a (scripted) namespace will do. The new doc will mention this.
If you decide to use a class you have to make sure the 3 basic fns <Help>, <List> and <Run> are SHARED PUBLIC.

if you start off with a non scripted namespace you will need to turn it into a scripted namespace to save it.
Doing
]save myns \ucmd\location\name
will do it automatically for you. If you want to preserve the scripted form in the workspace you should do
]save myns \ucmd\location\name -convert

[Phil Last]

The inexorable move towards Java, C and ultimately COBOL continues apace.

[Morten|Dyalog]

The inexorable move towards Java, C and ultimately COBOL continues apace.

Er Phil... What's your point exactly?

[Phil Last]

Just that Pierre would very much like to use separate functions in a namespace but is forced to ram them all together into a vast unmanageable script. Just like COBOL.

[DanB|Dyalog]

He WILL be using fns (and vars and whatever) in a namespace. But now he will have a source for it, just like you have a source for a function.
COBUG never had namespaces, it had ONE source, we have many. This is an improvement.

[Morten|Dyalog]

Also: Note that you do NOT HAVE TO use SALT to contain all the source code for a user command, if you find this so distasteful. The framework only demands that the "entry points" are in the script. The rest of the code could be copied from a workspace, held in a component file, or stashed away in the session object.

There has to be a standard mechanism for loading user commands, to make them easy to share, which is the main point of the exercise. Personally, I find that keeping all the source in a single text file makes my code easier to maintain than any other mechanism I have used in the past.

[PGilbert]

Thanks for the comments of everybody. Could I ask what is the technical reason for a Class not being able to store a variable (characters, matrix of number, etc.). I know it can be done if you 'build' your variable line by line in the Class, but you can't give the name of a variable to be included in the definition of the Class ? Or am I wrong ? I know that for another APL vendor on the same side of the pond as Dyalog, they can include a variable into the class and also they show the first comment line of each methods has a 'Resumé' of the class, wich I find helpfull but am I missing a bigger picture ?

Personnally I see a Class has a nice way to regroup functions (methods) that are related to each other and seeing the code of those functions has a whole is helping to keep the code clean and well organized. Too bad if the related variables (properties) could not be part of the Class. Like every good thing, too much is bad, if you make a Class of 10,000 lines its killing its purpose I think.

[DanB|Dyalog]

The problem is to write out the representation of the objects in the namespace.
In Dyalog you can do
:Namespace nn
a←⍳9
:EndNamespace

and further do
nn.b←⍳2 3
nn.⎕nl 2
a
b
but the representation has not changed and writing 'nn' to a text file ignores 'b'.
Even the competitor cannot do that.

[DanB|Dyalog]

Another thing one can do to insert data (or even code) into a space is to bring it in at []FIX time.
For example, if a large variable needs to be IN a space but that its representation is unimportant it can be brought in like this (for example):

:class X
...
BigVar<-⎕NREAD T 82,⎕NSIZE T<-'...\file'⎕NTIE 0
⎕NUNTIE T
...
:endclass

The source won't reflect the value of the var but this may not be important.