Ok, you convinced me.  Reopen the bug and lets change it to `when="..."`.  As a 
bonus, you can verify that the when condition is a valid compile-time 
conditional, but I'm pretty sure the script compiler will complain if it is not.

On 2010-05-15, at 09:13, André Bargull wrote:

> But valid (= currently supported) runtimes are only 'swf8', 'swf9', 'swf10' 
> and 'dhtml'. That means 'as3' is not a valid runtime identifier, but I think 
> we still want to have a pass through for both, swf9 and swf10, to avoid 
> duplicate code.
> (I know I'm a bit nit-picking right now, but this is my full intention, 
> because from the user's point of view the current rationale might be 
> confusing.)
> 
> 
> On 5/15/2010 3:00 PM, P T Withington wrote:
>> In the case of passthrough, where its intent is to "pass through" to a 
>> particular target runtime, the runtime argument seems most appropriate to 
>> me.  I suppose we should add some sanity checking that the runtime argument 
>> is a valid runtime.
>> 
>> If you really need a passthrough conditional to other properties, you can do 
>> so in a<script>  tag.
>> 
>> ---
>> 
>> The problem we are trying to solve here is that<switch>  cannot be used in a 
>> binary library (because its semantics are that it is evaluated at parse 
>> time).  Another approach would be to change switch to have an 'evaluation 
>> time' property, but that seemed like generality we didn't need.
>> 
>> On 2010-05-15, at 08:10, André Bargull wrote:
>> 
>>   
>>> We had first:
>>> <switch>
>>>  <when runtime="swf10">
>>>    <passthrough>
>>>      import flash.utils.*;
>>>    </passthrough>
>>>  </when>
>>> </switch>
>>> 
>>> "runtime" was only allowed to be: 'swf7', 'swf8', 'swf9', 'swf10' or 'dhtml'
>>> 
>>> 
>>> The first form was deprecated in favor of:
>>> <switch>
>>> <when property="$swf10">
>>>    <passthrough>
>>>      import flash.utils.*;
>>>    </passthrough>
>>>  </when>
>>> </switch>
>>> 
>>> "property" can be any of the compile time constants: '$swf7', '$swf8', 
>>> '$swf9', '$swf10', '$dhtml', '$as3', '$as2', '$debug' (left out some unused 
>>> constants)
>>> 
>>> 
>>> And now we're back with "runtime", although "runtime" is just any string 
>>> which will be transformed to the compile time constants from above (by 
>>> prepending "$" to the string).
>>> 
>>> <passthrough runtime="swf10">
>>>  import flash.utils.*;
>>> </passthrough>
>>> 
>>> But also possible:
>>> <passthrough runtime="as3">
>>>  import flash.utils.*;
>>> </passthrough>
>>> 
>>> or:
>>> <passthrough runtime="debug">
>>>  import flash.utils.*;
>>> </passthrough>
>>> 
>>> 
>>> So, maybe<passthrough>'s new "runtime" attribute should rather be 
>>> "property" like in<when>?
>>> 
>>> 
>>> 
>>> On 5/14/2010 10:46 PM, P T Withington wrote:
>>>     
>>>> Approved!
>>>> 
>>>> On 2010-05-13, at 17:19, Henry Minsky wrote:
>>>> 
>>>> 
>>>>       
>>>>> Change 20100513-hqm-p by [email protected] on 2010-05-13 17:17:23 EDT
>>>>>    in /Users/hqm/openlaszlo/trunk1
>>>>>    for http://svn.openlaszlo.org/openlaszlo/trunk
>>>>> 
>>>>> Summary:<passthrough>   should take a `runtime="..."` property
>>>>> 
>>>>> New Features:
>>>>> 
>>>>> Bugs Fixed: LPP-8995
>>>>> 
>>>>> Technical Reviewer: ptw
>>>>> QA Reviewer: (pending)
>>>>> Doc Reviewer: (pending)
>>>>> 
>>>>> Documentation:
>>>>> 
>>>>> Release Notes:
>>>>> 
>>>>> Overview:
>>>>> 
>>>>> 
>>>>> Details:
>>>>> 
>>>>> 
>>>>> Tests:
>>>>> 
>>>>> test case below, passthru should disappear in DHTML output:
>>>>> <canvas width="100%" height="80%">
>>>>>  <debug  fontsize="12"/>
>>>>> 
>>>>>  <class name="foo">
>>>>>    <passthrough runtime="swf10">
>>>>>      import flash.net.*;
>>>>>    </passthrough>
>>>>>    <method name="foo">
>>>>>      Debug.info('foobar');
>>>>>    </method>
>>>>> 
>>>>>  </class>
>>>>> 
>>>>> 
>>>>> </canvas>
>>>>> 
>>>>> 
>>>>> Files:
>>>>> M       WEB-INF/lps/server/src/org/openlaszlo/compiler/NodeModel.java
>>>>> M       WEB-INF/lps/server/src/org/openlaszlo/compiler/ClassModel.java
>>>>> 
>>>>> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20100513-hqm-p.tar
>>>>> 
>>>>>         
>>>> 
>>>>       
>> 
>>   


Reply via email to