Menu
▾
▴
Re: [Reuseware-devel] type casting in composition programs
|
From: Jendrik J. <jen...@tu...> - 2007-09-17 07:29:16
|
Hi,
I won't reply in detail. I think we should discuss this offline. I
wonder if you really need this type casting, or if the two types
(QuotedString and Location) should actually both be replaced by the
primitive type String. Then we would need primitive types in the type
system and need to define how primitive elements can be composed. Which
seems to be the most natural way for me.
The "casting" you propose may be incompatible wit the type system we
have, since we already have a type hierarchy for which casting could be
introduced.
Cheers,
Jendrik
Jakob Henriksson wrote:
> On Fri, 07 Sep 2007 23:38:44 +0200, Sven Karol
> <s78...@in...> wrote:
>
>> Hello again!
>>
>> We could do something which compares attribute types of two fragment
>> types to determine if a cast is possible. And if the attributes are
>> compatible we could create a new fragment of the type to which we want
>> to cast having the same values as the old fragment. But this is in fact
>> not casting, it is more like cloning or converting, since casting (in
>> the classical java sence) allways threats one object/fragment which
>> might be referenced by different variables/fragmentlists.
>>
>> >However, I'm guessing that this situation will appear in other
>> scenarios
>> >in the future as well. So, the question is what we should do.
>>
>> It happend allready to me, but I thought the string concatenation was
>> the way to go because it was implemented and used in some examples.
>
> Right, it works, which is nice for the moment. But in the long run it's
> not really desirable, since it is type unsafe.
>
> Cheers,
> Jakob
>
>> Sven.
>>
>>
>>
>>
>> Jakob Henriksson schrieb:
>>> Hi,
>>>
>>> They might not be type compatible, I'm not really sure. What I'm sure
>>> about is that I want a solution which doesn't step outside the type
>>> system (which is currently the case). Maybe a solution for Modular
>>> Xcerpt is possible to find, by using different types from Xcerpt, not
>>> to use componentmodel.Location etc. I don't know exactly in this very
>>> moment how it can be solved, but probably somehow.
>>>
>>> However, I'm guessing that this situation will appear in other
>>> scenarios in the future as well. So, the question is what we should do.
>>>
>>> Going back to the example. What I want to bind is a QuotedString (i.e.
>>> the slot). What I have is a Location. The value of a location is a
>>> string. If you define a QuotedString to be:
>>>
>>> QuotedString = "\"" value:S "\"";
>>>
>>> (or something to that effect), then the values of Location and
>>> QuotedString are really the same. Here, the '"'s are really just
>>> concrete syntax, aren't they? Somehow it seems that the values from
>>> the different types in this case can be cast to each other (it might
>>> not always be possible, but in this case it is, which is why we could
>>> successfully employ a cast).
>>>
>>> Anyway, discussion will hopefully continue.
>>>
>>> Please CC "Reuseware Developer"
>>> <reu...@li...> on all mailing discussions
>>> so that everybody can follow the discussions and so that it will end
>>> up in the mailing list archives later on. It will be interesting to
>>> have. It also shows some activity to the outside world ;)
>>>
>>> Cheers,
>>> Jakob
>>>
>>>
>>> On Fri, 07 Sep 2007 17:37:20 +0200, Sven Karol
>>> <s78...@in...> wrote:
>>>
>>>
>>>> Hi!
>>>>
>>>> I really dont know if a simple cast would be the right solution here,
>>>> since "componentmodel.Location" and "xcerpt.QuotedString" are not
>>>> type compatible (aren't they?). Because of that, you really need
>>>> that information about concrete syntax as it is used by the string
>>>> concatenation, so something like
>>>>
>>>> > bind moduleID on qtWrapper with
>>>> (xcerpt.QuotedString)'"'moduleID'"'.mxcerpt;
>>>>
>>>> is possible to be implemented. If we really want to have
>>>>
>>>> > bind moduleID on qtWrapper with (xcerpt.QuotedString)moduleID;
>>>>
>>>> reuseware would have to check all concrete Syntaxes registered as
>>>> parser/printer for "xcerpt.QuotedString" for prefixes and suffixes
>>>> ('"' and '"' in the case of mxcerpt) and do the string concatenation
>>>> internally. Of course this would work in some very special cases only
>>>> and has no clear semantics to the user. Additionally I currently do
>>>> not know if the concrete Syntax is accessible as far as one would
>>>> need for implementation of that feature, but I guess not.
>>>>
>>>>
>>>> greetz,
>>>> Sven.
>>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems? Stop.
>>> Now Search log events and configuration files using AJAX and a browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> _______________________________________________
>>> Reuseware-developer mailing list
>>> Reu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/reuseware-developer
>>>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Reuseware-developer mailing list
> Reu...@li...
> https://lists.sourceforge.net/lists/listinfo/reuseware-developer
|
