RE: references and concat

"Goldsack, Patrick" <[email protected]>
Newsgroups gmane.comp.java.smartfrog.user
Message-ID <[email protected]>
Andreas,

What an excellent example....

Yes indeed this will not work, and the reason is based on the order of
resolution.

The resolution of functions is done AFTER the references are resolved. So
the reference 

      string4 file1:string3;

is resolved before the concat function is evaluated. So you then end up
effectively with:

      string4 (string1 ++ " and " ++ string2);

Which, when resolved, cannot resolve string1 and string2 in the new
location. 

The best way of understanding what is going on is the use the sfParse tool
to look at all the phases as they occur and the expnasions that result.
I think the -v option switches this on.

This is all a result of the way in which the language has had these
additional features layered on the initial simpler base. The semantics have
some oddities! Language 2, of which I am about to release at least a parser
though not a resolution processor yet, deals with a lot of the semantics
issues of this kind and produces a clearer definition of what should happen.

However, there are some real semantic questions at the bottom of the reason
for the current semantics which also apply moving forward. If we remember
that functions are simply component descriptions that are handled at the
very end as indicating a function, we can simply think about the interaction
of component descriptions and references.

A component description is a set of attributes which may contain references.
We want to copy the component descriptions (as a result of reference or type
resolution) without resolving these contained references so that if we
override an attribute value in the copy, the references in the copy will now
resolve using the new value and not refer to the old.

This seems fine for a "closed" component description - one in which
references do not map to something outside of the component description
being copied. Perhps "free" references, those that map out of the CD, should
be bound before copying... (string1 and string2 are free in the component
description that is string3 in your example). This might be a reasonable
decision, but expensive to calculate and more complex to implement.
Consequently, for the moment we re-resolve all references after a copy and
don't distinguish between free and bound.

Hope this helps in explaining, even if not in fixing...

Patrick


-----Original Message-----
From: smartfrog-support-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:smartfrog-support-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Andreas
Unterkircher
Sent: 23 June 2004 12:33
To: smartfrog-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: [Smartfrog-support] references and concat



Hello,

I encountered one problem concerning resolution and concat of strings. Let 
me illustrate it with a small example (I omit the "#include..." 
statements) consisting of 3 components (file1.sf, file2.sf, file3.sf):

file1.sf:

file1 extends {
 string1 "string1 in file1";
 string2 "string2 in file1";
 string3 (string1 ++ " and " ++ string2);
}

file3.sf

sfConfig extends Compound {
 a extends file1;
}

This works fine, "sfParse file3.sf" yields:

sfCodeBase "default";
sfClass "org.smartfrog.sfcore.compound.CompoundImpl";
a extends  {
	string1 "string1 in file1";
	string2 "string2 in file1";
	string3 "string1 in file1 and string2 in file1";
}

SFParse: SUCCESSFUL

Now I introduce a component file2:

file2 extends {
 string4 file1:string2;
}

I change file3 to:

sfConfig extends Compound {
 a extends file2;
}

This works also fine, "sfParse file3.sf" yields:

Parser - SmartFrog 3.02.002_beta
(C) Copyright 1998-2004 Hewlett-Packard Development Company, LP
 
sfCodeBase "default";
sfClass "org.smartfrog.sfcore.compound.CompoundImpl";
a extends  {
	string4 "string2 in file1";
}

SFParse: SUCCESSFUL

Now I change file2 to reference the concateneted string from file1:

file2 extends {
 string4 file1:string3;
}

This doesn't work, "sfParse file3.sf" yields:

Parser - SmartFrog 3.02.002_beta
(C) Copyright 1998-2004 Hewlett-Packard Development Company, LP
 
ERROR 'file3.sf': 
SmartFrogCompileResolutionException:: Unresolved Reference, data: [string1 
in: HERE sfConfig:a:string4, string2 in: HERE sfConfig:a:string4], source: 
HERE sfConfig, resolutionPhase: link

Error detected. Check report.
SFParse: FAILED

Why doesn't this work ?

Thanks,
Andreas

-- 
http://cern.ch/openlab


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black
Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Smartfrog-support mailing list Smartfrog-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/smartfrog-support


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.