Dear Maxim,

here the code for the old and new example with expected output.

-g

Original example:

============================================================   nx::Class create dzs {     :property {srv:substdefault {[ns_info server]}}   }   dzs create o1

nx::Class create dz -superclass dzs dz create o2

lappend _ [o1 cget -srv] [o2 cget -srv] # returns a list containing the name of the current server twice ============================================================

New example

============================================================ nx::Class create D nx::Class create FOO { :property {d:object,type=::D,substdefault {[::D new]}} :create o3 } set o [o3 cget -d]

$o info class # returns ::D ============================================================

On 12.08.22 20:40, Maksym Zinchenko wrote:

Dear Gustaf, sorry I've tried to remove the comma but it breaks the code completely. And I can't see minimal example also. I based my code on an example in the next-scripting tutorial (3.7.6. Defaults substitution):

:property {d:object,type=::D,substdefault {[::Dnew]}}

On Fri, Aug 12, 2022 at 4:00 PM Gustaf Neumann neumann@wu.ac.at wrote:

Dear Maxsym,

the comma after the variable name "srv" was not correct.
We should provide an error message for that....

See below for a minimal example showing the correct behavior.

all the best

-gustaf

On 12.08.22 16:25, Maksym Zinchenko wrote:
> Hello, I'm having trouble to define "srv" property in my
superclass with
> default value from Naviserver command, may be Im doing smth
wrong, would be
> so kind to help:
>
> nx::Class create dz_superclass {
>> :property identifier
>> :property {srv,substdefault=0b111: {[ns_info server]}}
>> :method init {} {
>> set :uuid ""
>> if {[[current object] info vars identifier] eq ""} {
>> set :identifier ""
>> } else {
>> if {[is_uuid ${:identifier}] == 1} {
>> set :uuid ${:identifier}
>> }
>> }
>> }
>> }
> nx::Class create dz_class -superclass dz_superclass {
>> :method init {} {
>> if {${:identifier} ne ""} {
>> set :obj_data [dict getnull [select_all client *
>> uuid_client=\'${:identifier}\'] 0]
>> }
>> }
>> }
>>
> When I create object:
>
>> dz_class create o1 -identifier 67720c6d-d00f-479b-85cf-4edaa5a9cb1a
>>
> o1 cget -srv
> Im getting literal "[ns_info server]" instead of my virtual
server name
>
>
>> [ns_info server]
>>
> Thank you

Thank you Gustaf, I can see that the problem is in freedom, and people say that freedom is a good thing :) This works as I expected:

:property {srv:substdefault {[ns_info server]}}

About the suspicious characters, I doubt that there will be people who will name their properties like this: ',&';/', I think we can even limit it to alphanumeric characters without punctuation.

Thanks again for the excellent explanation and examples.

On Sat, Aug 13, 2022 at 9:28 AM Gustaf Neumann neumann@wu.ac.at wrote:

Dear Maxym,

I've looked again into your original problem, concerning measures to address the problem earlier. The problem is that nx/xotcl are very liberal on what is allowed as a property name (maybe sometimes too liberal). In the example, the string "srv,substdefault=0b111" is interpreted as the name of the property. When accessing the property, the name abbreviation rules kick in, and one can access it via "-srv", but as well via every other abbreviation such as "-srv,subst". Since the whole spec is treated as a name, "substdefault" does not kick in.

I have added now a warning to complain about suspicious characters in a property name, that hints an error (here a ",").

We are close to a new release of NSF, but I will wait for your feedback....

all the best

-gustaf

% nx::Class create dzs { :property {srv,substdefault=0b111: {[nsf::is object ::nx::Class]}} :create o1 } ::dzs % % o1 cget -srv [nsf::is object ::nx::Class] % o1 cget -srv, [nsf::is object ::nx::Class] % o1 cget -srv,subst [nsf::is object ::nx::Class] _______________________________________________ Xotcl mailing list Xotcl@alice.wu.ac.at http://alice.wu.ac.at/mailman/listinfo/xotcl