Cobra Forums

Does Cobra support default parameters? If it does, what is the syntax for doing this, and if it doesn't , are default parameters expected any time soon? Thanks,

FierceForm

It does not support them right now, so the trick is to use overloads to simulate them:

I realize that is not as convenient, but it's doable. I'm in favor of default values, but it might be some time before they are added because there are other things coming up:
-- subcommands
-- refine the symbol lookup for attributes
-- bona fide .NET 4.0 support
-- cut a release somewhere in here
-- multiline strings
-- misc web site refinements
-- outstanding patches
-- ...

There is no rest for the wicked.

I would like to suggest (respectfully though somewhat snottily) that given
a) the number of outstanding/pending patches and
b) the duration that some of them have been waiting for some/any sort of action
c) the utility and size of some of them and
d) that they are all addressing something someone has requested/found broken in the language
it might be prudent to do something about them a little higher up the 'things coming up' list than the final item
especially since no one else can do so...

Secondarily, 'the wicked' might attain more scope for rest if they put some of these items that anyone else could do on tickets (with or without descriptive/prescriptive specs)
and kept an eye open for results (specifically item 2 and this topic)
and provided feedback on any perceived deficiencies in anything that did eventuate (item 5).

Frankly, I haven't really enjoyed applying many of the patches which I sometimes have to rewrite, heavily modify or reformat. Previously, I would give feedback, but even on simple requests like "Please use doc strings instead of top comments" and "don't mixCase andspac ing randomly", I would continue to get more patches that did these things. I then stopped giving feedback.

And the non-patch bullets also address things that people have requested/found which makes them also important.

I'm sorry chuck, I hadn't realised that one of the requirements for having something actually be done with a provided patch was that you have to somehow find some arbitrary level of enjoyment from the act of applying it.
I'd have thought that the fact that you had a patch of some description at all (even if only as a starting point) would give you enough jollies to at least look at it and comment on it.
Oh well, wrong again....


I'd also like to point out also that you dont have to rewrite, heavily modify or reformat the patches, you choose to do so based on some arbitrary, internal, constantly changing set of criteria known only to you which you seem unable to clearly articulate (individually at least)

Ideally I'm sure you'd love to get only patches that did everything the way you would do them and you could just patch them straight in. Realistically you will never get that if only because no-one else has your knowledge of the code base and no-one agrees exactly on naming and commenting and puts code together exactly the same way...
So either your patch reworking is part of the apply process (enjoyable or not) or apply them as is (and live with the distastefulness of someone elses code ) or ignore the contribution ( but dont wonder why they stop coming).

I believe the top comment vs doc string thing has been corrected but if not is that really the most important thing in a code patch to be concerned about?
And while you may call the commenting 'randomly mixingCase and spacing' that's not necessarily the way everyone sees it
and once again is that the best reason for ignoring tickets/patches altogether ?


I'm hoping its not the case but it looks like what you just said was that because you didnt like the layout of (some ) of the code comments in patches you ceased to say anything about any of them (??)

(Or so far as I can tell, even look at any of the patches at all...)
How is that supposed to help things along ??


re the other non-patch bullet points, Id agree regarding the importance of a new release, the rest is navel lint twiddling
( really, subcommands??)

We'll just have to agree to disagree at this point. These points had been communicated before which means they are not "constantly changing". Whether or not they are "arbitrary" can be debated, but I don't think anything fruitful would come out of it.