ooc-dev team mailing list archive

[Amos Wenger <amoswenger@xxxxxxxxx>]

I doubt ooc is a super-set of bash =) Although allowing the
shebang<http://en.wikipedia.org/wiki/Shebang_(Unix)>may not hurt,
especially with -tcc and lib-caching, where it takes <300ms to
compile simple apps =)

On Wed, May 12, 2010 at 9:58 PM, Bart van der Werf <bluelive@xxxxxxxxx>wrote:

> i suggested # for easier bash/sh repl integration.
>
>
> On Wed, May 12, 2010 at 2:49 PM, Wander Nauta <info@xxxxxxxxxxxxxx> wrote:
>
>> Noob here :)
>>
>> I agree with Amos - # for macro ánd comment seems odd. C and friends use #
>> for macro's only, and PHP supports # for comments but complains about it. I
>> wouldn't like using a space to distinguish between a comment (no op) and a
>> macro (can be disastrous).
>>
>> Anyhoo, macros are one of the things I don't like about compiled
>> languages. I think they are the wrong kind of language-in-a-language.
>>
>> Just my 2c...
>>
>> Wander
>>
>>
>> On Wed, May 12, 2010 at 14:34, Amos Wenger <amoswenger@xxxxxxxxx> wrote:
>>
>>> I'm not sure. #foo macro vs # comment seems to confusing / easy to make a
>>> mistake.
>>>
>>> Ideally one could use # in any context, such as:
>>>
>>> Vector3f := #Vector(3, Float)
>>>
>>> On Mon, May 10, 2010 at 12:53 PM, Bart van der Werf <bluelive@xxxxxxxxx>wrote:
>>>
>>>> # for macros makes sense, what about
>>>>
>>>> #foo macro
>>>> # comment
>>>> #! hashbang
>>>>
>>>>
>>>> On Mon, May 10, 2010 at 11:46 AM, Amos Wenger <amoswenger@xxxxxxxxx>wrote:
>>>>
>>>>> hmm I prefer 4 spaces, and most ooc code is already written that way.
>>>>> If you think it's too much, you're using too much nested structures anyway
>>>>> =)
>>>>>
>>>>> As for the line length I don't really have any strong opinion either
>>>>> way.
>>>>>
>>>>> As for allowing the '#' for single-line comments, I'm not too sure. I
>>>>> was thinking of reserving that character for macros.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Amos Wenger (nddrylliog)
>>>>>
>>>>>
>>>>> On Mon, May 10, 2010 at 11:41 AM, Bart van der Werf <
>>>>> bluelive@xxxxxxxxx> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Bart van der Werf <bluelive@xxxxxxxxx>
>>>>>> Date: Mon, May 10, 2010 at 11:40 AM
>>>>>> Subject: Re: [Ooc-dev] OOC best practices
>>>>>> To: Friedrich Weber <fred.reichbier@xxxxxxxxxxxxxx>
>>>>>>
>>>>>>
>>>>>> :)
>>>>>>
>>>>>> Indentation: 2 spaces
>>>>>> Line length: no limit (160) 80 is far too short for modern monitors.
>>>>>> Encoding: Utf8 (bom explicitly allowed, suggested, but not required)
>>>>>>
>>>>>> Whitespace:
>>>>>>
>>>>>> space after functionlike keywords(if/while)/blocks to avoid confusion
>>>>>> with calls.
>>>>>> space around operators
>>>>>> nospace inside()
>>>>>> no trailing statements after conditional
>>>>>> allow ommision of {} for single line single statements.
>>>>>> lowerCamelCase for locals/arguments/private fields
>>>>>> UpperCamelCase for globals and types
>>>>>>
>>>>>> Comments:
>>>>>>
>>>>>> besides // and /*(*) i would suggest alowing # as the first char on a
>>>>>> line as a start of a comment.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, May 2, 2010 at 2:54 PM, Friedrich Weber <
>>>>>> fred.reichbier@xxxxxxxxxxxxxx> wrote:
>>>>>>
>>>>>>> Huhu!
>>>>>>>
>>>>>>> On 02.05.2010 13:43, Fabien Bourgeois wrote:
>>>>>>> > OOC API isn't already consolidated but, with rock, I think we can
>>>>>>> say
>>>>>>> > that pretty few things will change around current syntax and
>>>>>>> grammar.
>>>>>>> >
>>>>>>> > So, can it be interesting to begin to set a *best practices guide*
>>>>>>> ?
>>>>>>> > The goal isn't to constrain anybody but I think some little rules
>>>>>>> can
>>>>>>> > help about readability and code reuse.
>>>>>>>
>>>>>>> Yeah, we certainly need this! I'll just throw in my opinion here. :-)
>>>>>>>
>>>>>>> > Can we start to talk about it ? An example can be the Python style
>>>>>>> guide
>>>>>>> > : [http://www.python.org/dev/peps/pep-0008/]. Points that should
>>>>>>> be
>>>>>>> > discussed :
>>>>>>> >
>>>>>>> > * Indentations
>>>>>>>
>>>>>>> I like Python, I like 4 spaces.
>>>>>>>
>>>>>>> > * Line length
>>>>>>>
>>>>>>> Hm. 79 characters as a guideline?
>>>>>>>
>>>>>>> > * Encodings
>>>>>>>
>>>>>>> UTF-8?
>>>>>>>
>>>>>>> > * Whitespaces
>>>>>>>
>>>>>>> I also like Python's style here, with one exception: Function
>>>>>>> definitions should have a space between the `func` keyword and the
>>>>>>> arguments::
>>>>>>>
>>>>>>>        doSomething: func (...) {
>>>>>>>                /* ... */
>>>>>>>        }
>>>>>>>
>>>>>>> > * Naming conventions
>>>>>>>
>>>>>>> We should use thisStyle for functions and variables,
>>>>>>> UppercasedCamelCase
>>>>>>> for classes, covers etc. and UPPERCASED for constants (huh, looks so
>>>>>>> aggressive)
>>>>>>> Package names should be lowercased (net/, io/, lang/). I'm not sure
>>>>>>> about modules. What about this: Capitalized if mainly containing a
>>>>>>> class
>>>>>>> of this name (structs/HashMap), lowercased if the module name is more
>>>>>>> of
>>>>>>> a description of its contents? (lang/types, ...).
>>>>>>>
>>>>>>> > * Comments
>>>>>>>
>>>>>>> Hm. // for one-line comments, /** */ (oocdoc) for documentation, /*
>>>>>>> */
>>>>>>> for everything else?
>>>>>>>
>>>>>>> > Apart from style guide, I d'like to talk about documentation.
>>>>>>> Python
>>>>>>> > (it's my world, sorry) uses docstring
>>>>>>> > [http://www.python.org/dev/peps/pep-0257/]. What's your point of
>>>>>>> view
>>>>>>> > about standardizing how we should document our ooc projects ?
>>>>>>>
>>>>>>> Well, we theoretically support everything that sphinx supports, with
>>>>>>> some extensions. ooc-docs uses a sphinx extension that adds some
>>>>>>> ooc-specific roles and refs (so you can do :cover:`String` to
>>>>>>> reference
>>>>>>> String, for example)
>>>>>>>
>>>>>>> > In my mind, if you're allright about using a lightweight markup
>>>>>>> > language, there are two good candidates :
>>>>>>>
>>>>>>> Hm, I smell problems since we're using MD for ORCs and RST for docs.
>>>>>>> If
>>>>>>> we need a universal choice, I'd also tend to use reStructuredText.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Friedrich
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~ooc-dev
>>>>>>> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~ooc-dev
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~ooc-dev
>>>>>> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~ooc-dev
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~ooc-dev
>>> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~ooc-dev
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~ooc-dev
>> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ooc-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ooc-dev
> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ooc-dev
> More help   : https://help.launchpad.net/ListHelp
>
>