ooc-dev team mailing list archive

[Iván Hernández Valmisa <ivanhv77@xxxxxxxxxxx>]

Hi, everyone.

Recently I found ooc. It's amazing how it molds to some language syntax ideas I had for a language (messaging with no dots like in IO, lambda functions syntax, an easy to type symbol for method chaining, type inference in preference of dynamic types, an easy way -like covers- for ffi and c code interoperation...)

But, being an active C# programmer, a previous C++ expert (yes, I know that's not possible ;)) and a lisp/scheme don't-get-the-whole-point-but-looks-like-if-it-rocks I find some real missings on current ooc language. It would be great to know what are the expectations for implementing this on the specs of ooc (I assume ooc language definition is no actually carved in stone):

- Properties (or getters/setters). They can be treated as a syntax trick if reflection on these is not a requirement. So easy to implement (as syntax sugar) and so easy to read on written code... They work like methods (they would be c functions in translated code, in fact), but they taste in ooc like regular attributes of an object.

- Metaclasses (like c# class attributes or java adornments). When you declare a class, you can attach some other classes to it providing information (and functionality) related to this class. In c#, the most pragmatic example is the class XmlSerialization, that states a class can be serialized to Xml and provides the necessary code for doing it at start time. By the way, I find Python or Lua style metaclasses much less useful in a static language. 

- Mixins. In a language with single inheritance, they are required if you don't want to pollute your namespaces with little classes with lots of common code for providing interface implementation. (There are other solutions, but mixins like in D language seems to me the most effective way)

- Dynamic message resolution operator. In a static language it seems a bit weird to provide something like this, but being able to dynamically change message calls functionality is eventually so useful, that being able to do it with an special syntax feels great (even on a language that was supposed to work with static typing). Fan is a recent language that incorporates this.

- Macros (can they be hygienic, please?). In a language that it's not homoiconic, could be difficult to implement and use, but they are designed to do what c++ templates were forced to do and allow for code generation in static time. That means all the previous points in the list could be implemented in terms of compiler macros. As a weird alternative, I was thinking in the possibility of having something like "compiler plugins". The programmer declares a word/sequence of symbols as a kind of trigger, that will make the compiler look for it's corresponding plugin: an external process that will parse itself the associated code and that'll generate occ code on it's standard output, being captured by the compiler and replacing the original macro call text. It would be like having an external macro processor (as m4 is), but embedded within the compiler. All this would open ooc to the world of DSLs and something like LINQ could be implemented in terms of macros, instead of having to incorporate it to the compiler.

- A GREAT manual. "Great" in caps. It should describe the language, so there's no doubt what it can do and how.

That's my point of view of what would be great to see in a modern language like ooc. I really feel the manual is a requirement and properties and mixins are a "must have", being the other options great features everyone could pass without but would enrich any language.

Is there any thoughts about incorporating any of these in ooc in a future (let's say from "just now" to "your grandsons will see all those")?

By the way, I'm from Spain, and must apologize for my loose English. Anyway, I hope it's good enough to properly translate an English text to Spanish. Even a GREAT manual. So if you need some help with this some day...

Greetings.
 
 		 	   		  
_________________________________________________________________
¿Aún no sabes qué móvil eres? ¡Descúbrelo aquí!
http://www.quemovileres.com/