WinRT and dylan - first insights

Hi, Dylan Folks,


With Win 8 Microsoft steps back from .NET to COM and forward from Win32 to WinRT.

To understand that better I look into two old books written by Don Box. He is a brilliant technical writer.

Both books from Don Box I'm currently reading are about construction of large systems or  called it "Designing component-based architectures".  

I drop here some notes, which I like share to the dylan community.

(1) assemblies by far more component-oriented than dylan's define library.

There is a great similarity between both, yes. But assemblies really have some features which can help to evolve dylan to a mainstream language in the context of component-oriented programming. e.g.
 - the kind of versioning
 - the separation of the manifest form the code, which is necessary to
   support web distributed components

(Well, and the binary reuse topic, of course, too. 
More about this in a next email)

see: Don's "Essential .NET" for details


(2) Don's phrasing of what is component-oriented is short:

 Component-Oriented Programming
 = Polymorphism
    + (Really) late Binding
    + (Real, Enfored) Encapsulation
    + Interface Inheritance
    + Binary Reuse

(Ok, this makes clear: we need a statement relate to the binary reuse.
But I still have to digest some stuff before writing about this)

That's quoted from Don's  "Essential COM". In that book Don describes well that the binary reuse of C++ code is one of the core idea behind COM. 

As I'm reading more about WinRT I get the feeling that supporting WinRT by the dylan language makes sense for both: 
   Dylan and WinRT.

I currently also trying to grasp the essence of Partition II 
  "Metadata Definition and Semantics"
of the Standard ECMA-335 to better understand the concept
  "Language Project"
which comes with adapting a non .NET language to WinRT.
(The next email will focus on this topic.)

My insights related to a dylan to-do list to adapt to WinRT are currently minor ones, but ones of general importants, too:

There was a discussion about simplifying the dylan module concept on the dylan channel. I like to mention here, that .NET's qualified namespaces (like System.Xml) are nothing more than prefixes to a .NET module, this could be adapted to simplify the module concept. But from my point of view such a simplification does not have currently a high priority. 

  In my opinion more it is more important that the code of the open dylan compiler itself uses the concepts of roles described in the Dylan Programming Chapter 13. This would 
(1) enforce the process of redesigning the IDE on Windows.
(2) enforce that a programmer can navigate throught the dylan compiler code, well.

( If I start hacking on open dylan (1) and (2) would be my first tasks any way. )


If someone likes to ask 
   "why are these two steps are really important?"

After skimming over Stanely B. Lipperman's book
   
  "Inside the C++ Object Model"

I'm convinced that transparency about the implementation of dylan is the way
to convince the C++ community that dylan is a great mainstream language.

In my opinion Visual C++ with its CX extension will open the minds of all Microsoft Visual C++ programmers for dylan as mainstream language in the near future.

Maybe we can ask Microsoft to finance a dylan relaunch. Strange tought, but in the current situation I really think that this could be a win-win situation for both Microsoft and the Open Dylan community.

(May be I should explain this in the next email a little bit more.)



Greetings,
   petro


The online accessible versions of the cited literatur
-  I myselft enjoy having a printed copy and a marker by my side :-)
  
"Essential .NET"  

"Essential COM" 

"Inside the C++ Object Model"

PS: Carl, if you need some arguments why dylan is better than C++,
    I recommend reading "Inside the C++ Object Model" with dylan im mind.
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers