Cobra Forums

hi guys,
what do you think about features such as multiple return values (implicit tuple creation based on return types)
or about integrating a mocking library, to be used for quick skeleton building (stubs or fakes) similar to pass, but for all types.
what about exposing the macro api for creating new constructs, etc.
or a little crazier ideas such as using a library along with new syntax to vastly simplify network operations (e.g: zeromq? msgpack?) or "first class" handling of various data types (as done in languages such as rebol)?
what about generating constructors implicitly by marking fields as required (saw that in tcl's nsf newscriptingframework)

Basically, is everybody happy with the language as is, stable, safe, readable, and 'help'ful (cobra is great with error msgs)?
Are those too experimental? or maybe too far from the direction of the language, or next steps as you envision them?
I am simply asking, to know what to expect, not trying to push in either direction.

kobi

At one point I scaled back my exploration of new features because we were still finding bugs in the old features. However, in my last Cobra-based project things went fairly well. Nevertheless there are still outstanding issues:

-- a bug around method overloads that I found
-- looking into the safe nil dereference operator which hopscc did some work on.
-- issues around mix-ins
-- other tickets that need to be looked at
-- multi-line strings
-- reading C# extension methods so they can be used by Cobra programmers.

So there is plenty of work in the queue right now.

Out of your list, the mocking library interests me the most as it would dovetail nicely with built-in testing. If you have specific ideas, you could start a new thread with your current thoughts.

Btw if your properties are read+write, then you can do:

I wouldn't mind seeing multiple return values at some stage. In the interim, I've effectively abused

Code: Select all

def sqlSearch(querystring) as List<of String>?

for my own purposes in at least one program. If I was a serious programmer instead of an unreliable dabbler I should probably have used a class instead of abusing a list.

However, multi-line strings and C# extension methods (especially access to System.Linq) are good priorities (from my selfish point of view).

There is a patch for multiple-return values on ticket:315 and a bit of a discussion for
how its almost-doable-now on idea: multiple return values.

Multiline strings: patch on ticket:120
discussion Multiline Strings.

The macro capability is doable now - we call it hacking on the compiler
Veering more into Boo territory which wasnt really one of the original features/targets for Cobra.

What were you thinking of as ideas or examplars for simplified network operations library (new thread)?

What would be characteristics of ' "first class" handling of various data types (as done in languages such as rebol)' ?

Personally I dont see much value ( and a lot of non-value) in implicitly generating ctors -
I prefer that even simple construction is explicitly expressed - but thats just me ....

hi hopscc, recently i delved into code a little more, and i like what i see. very clear and readable.
i haven't touched dynamics in Cobra before, and that was a neat surprise.
the features are not meant as 'cobra sucks', but as 'wow this is a wonderful language. it would be even better if...'

hopscc wrote:The macro capability is doable now - we call it hacking on the compiler

tempting. I actually read some of the compiler code with regard to parsing.
I wanted to understand how things work.
charles is a very good coder and the design is really nice in my opinion, I just noticed how the places that can be extended and claim more features are independent and easy to extend, so progress is quick, and fixes are short.

hopscc wrote:What were you thinking of as ideas or examplars for simplified network operations library (new thread)?

I remember when just starting on C# coding, that there was no event for when new data is on the socket, and the whole low level socket handling felt quite backward. I was thinking of a 'mailbox' idea (erlang style) or basically message queues could simplify and provide a higher level experience. (there are some small libraries for that too)
this can be a library ofcourse, but some things are common to many applications (network, gui, file access, string operations, ...) and maybe would be useful with a tighter integration to the language.

hopscc wrote:What would be characteristics of ' "first class" handling of various data types (as done in languages such as rebol)' ?

The syntax would feel as a part of the language: iterate a file as you would with any sequence in memory, handling a picture as you would access a 2d-array. it's like implementing interfaces and keeping a simple api, yet under the hood wild things can happen. I am not sure if this is the domain of a language. it's just the vast simplification that blessing a library into the base tree, and making sure the library feels like a part of the language, adding new constructs if needed, generalizing syntax and flow etc.

hopscc wrote:Personally I dont see much value ( and a lot of non-value) in implicitly generating ctors -
I prefer that even simple construction is explicitly expressed - but thats just me ....

Maybe you're right.
what i found was that ctors start innocent, but then someone decides to initalize database tables inside them.
i think ctors should just accept the external data that the class needs to operate on its own.
then you can have other methods like initialize or addData.
having it implicit can guard against this problem. a ctor would just give you a new object, and that's it.
the main reasoning is maintainability. a keyword like 'required' is put next to the specific fields in the class.
so it is kind of explicit.
all of these features are just a brainstorming kind of thing. I hope you guys take it easily, sometimes I fail to pass my intention well (and for that sorry)