2012/2/19 Roland Zwaga <rol...@stackandheap.com>:
>>
>> First of all. Why Java (JVM)? Why use this piece of corporative neo-COBOL
>> invented for the sole purpose of allowing cheap labor force to further
>> bloat the bloatware? For once you have the full carte blanche to start
>> anew, and you choose nearest to worst option? Compiler is unlikely to drive
>> a lot of attention of the programmers typically writing in Java. On the
>> other hand, programmers who are interested in language design are very much
>> unlikely to be attracted by Java. I'd look into the following options,
>> which are all viable, in my opinion:
>>
>
> I think the main reason for using the JVM is because of the amount of Java
> (and other
> JVM languages) knowledge that is available.
> The other languages that you suggest probably have lots of advantages over
> Java but,
> from what I know, they are not very widely adopted. Should a new compiler
> be built
> it would be very important that it'll be extensible. So that people will
> have a low barrier
> for creating their own extensions to it. If they are required to develop
> these extensions
> in a language that they haven't ever used it would automatically require
> them to learn
> a new language while all they want to do is build a simple compiler plugin.
> For a lot of folks that would be reason enough not to pursue the idea in
> the first place.
> When choosing the JVM they can choose from any of the available JVM
> languages,
> not necessarily Java.
> It might be worth considering building certain parts in C I guess, but that
> would add the
> extra burden of making sure the C based parts are cross-platform compatible.
> I mean, I'm pretty sure the aim is to have a compiler run on windows, mac
> and linux.
So basically, we are going to choose extensibility over performance?
>> <fx:DataGrid ...>
>> <fx:columns>
>> <fs:DataGridColumn label="{Foo.BAR}" labelFunction="{labelFunction"}/>
>> <fs:DataGridColumn label="{Foo.BAZ}" labelFunction="{labelFunction"}/>
>> <fs:DataGridColumn label="{Foo.BOOZ}" labelFunction="{labelFunction"}/>
>> . . .
>> <fs:DataGridColumn label="{Foo.CHAMPAIGN}"
>> labelFunction="{labelFunction"}/>
>> </fx:columns>
>> </fx:DataGrid>
>>
>> You copied words "DataGridColumn", "label", "Foo", "labelFunction",
>> "labelFunction" how many times? Whereas you could do:
>>
>> var dataGrid:DataGrid = new DataGrid();
>> for (var p:String in Foo) dataGrid.columns.push(makeColumn(p));
>> function makeColumn(label:String):DataGridColumn { return ...; }
>>
>
> I think it would be rather hard to express a loop construct in an XML
> dialect,
> I'm sure it's possible but then you'd be creating a programming language
> in XML which kind of defeats the purpose. All in all I don't think MXML is
> THAT
> verbose. The data column example you mention is an exception, IMHO.
> Sure, MXML is open to improvement and should you have any input for this,
> please share with us. But suggesting to simply 'dump' it seems a tad
> over-enthusiastic :)
>
XSLT can solve the problem of loop constructs in XML
Regards
--
Mansour Blanco
Software engineer
Stackoverflow: http://stackoverflow.com/users/612920/mansuro
Blog: zuro.blogspot.com
github: https://github.com/Mansuro
