ooc-dev team mailing list archive

[Tres Walsh <tres.walsh@xxxxxxxxx>]

>>    1. Guideline - A guideline dictates a way in which ooc workflow is
>> to be performed, from code generation, to compiler implementation, as
>> well as any other role that would require a rule of some sort.
>
> Does this also include code style guidelines?

 Yes. A coding style ORC much like PEP should be one of the first ORCs
 written in my opinion. So far everyone seems to be emulating the SDK
 as best they can, which is alright, but a set in stone "Standard
 Library" coding style would benefit the community greatly. (As
 language features are added, this ORC would be updated of course :D )

>>    3. Extension - An extension is any additional library. This could
>> be anything from a language bridge (e.g. ooc to Python), to a platform
>> specific feature (e.g. DirectX or Cocoa bindings). As these are not
>> part of the core ooc language, they are not required to be implemented
>> by implementations other than the core ooc implementation (i.e. rock).
>
> Does this only affect additions to the standard library?

 Well it would totally be up to the implementation I guess. Granted
 some systems can't do threading (Sony's PSP. It's a cooperative
 multithreading environment), so one could argue that the threading
 portion of llamacore would be non essential for a basic ooc
 implementation per platform. Another example could be someone trying
 to create a blazing fast implementation of ooc, but only focus on
 extensions for say Linux, which means threading, networking, sound, or
 what have you would not have to work on all platforms, but their core
 implementation might work perfectly on everything ever :)

 If I didn't answer this question properly forgive me, I found it a bit
 confusing :X

>> After 1 year, the Author of a rejected ORC may make a case to move
>> their ORC from rejected to accepted. At this point the ORC will be
>> placed in draft status, and the community will once again be allowed
>> to voice their opinions. There is no limit as to how many times an ORC
>> may be tasked for re-evaluation.
>
> Hm, I find 1 year a bit too long, compared to the age of ooc ;-) Maybe
> change this to 6 months?

 It was just a silly measure of time. 6 months would most likely be best :)

>> License:
>>
>> All ORCs are released in the public domain, and as such are not
>> required to state any license agreement.
>
> Don't want to be nitpicky here, but can we use a free documentation or
> creative commons license here? I'm not sure, but AFAIK there is no such
> thing like "public domain" in some European countries (at least Germany).

 I wasn't aware of that. I'm all for a creative commons license :)

> I like the idea of ORCs, also I like this acronym. So thanks for this
> ORC ORC ;-)

 Glad you like it :)