-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi there,
I'm not completely convinced we need another syntax element for
creating arrays. For example, Python supports a simple way to create
arrays, and in fact it is so simple programmers sometimes forget they
are creating arrays. I've seen quite some code where the use of the
simple array creation operator caused a major performance hit. I don't
think it would have happened if the programmer was really aware that
he was creating a new array. That's why I like the more verbose
approach of using .Array~of(...). And I'd really like to be able to
specify the type of object that the notation creates. Hence, I'd
propose that the array class implements the [] method, i.e.

    .Array[1, 2, 3]

being equivalent to

    .Array~of(1, 2, 3)

It's a bit shorter but still forces programmers to think about the
type and that there's actually a new object created.

Moritz

On 09/18/2014 10:28 PM, Sahananda (Jon) Wolfers wrote:
> I agree with David about double brackets, but I don't agree that
> sugar makes one unproductive or hinders understanding - in fact I
> think the opposite is true.  One doesn't want to be coding '=' or
> '[]' with a preceding twiddle.
> 
> I think that
> 
> do name over ['David','Rick','Jon']
> 
> is easier to understand than
> 
> do name over .array~of('David','Rick','Jon')
> 
> even though 'of' is a nicely contextualised word they don't need to
> know that there is an array behind the do over mechanism.
> 
> Jon
> 
> On 18 September 2014 19:54, David Ashley <[email protected]>
> wrote:
> 
>> I want to stick my thumb in the pie on this topic.
>> 
>> I think we need to be very careful of how much syntactic sugar we
>> add to the language. Otherwise we might end up being like Perl
>> with eight different ways of coding everything. I like
>> Rexx/ooRexx because the language is consistent and easy to
>> read/debug. The more syntactic sugar you add, the harder it is to
>> read and you end up having to look up things you do not
>> understand or have not encountered thus slowing your 
>> productivity.
>> 
>> And the idea of double brackets - YUK! Reminds me of Lisp which
>> IMHO is the least user friendly language I have ever
>> encountered.
>> 
>> Bottom line, syntactic sugar should only be added when it
>> clearly enhances productivity or makes the code easier to read.
>> 
>> David Ashley
>> 
>> On Thu, 2014-09-18 at 13:41 -0400, Rick McGuire wrote:
>>> I think these do need to be bracketed, since the "," is already
>>> used in the IF/WHEN instruction and with DO WHILE/UNTIL for the
>>> shortcut AND conditionals.  Square brackets are already used as
>>> a message type (primarily with collection objects), but
>>> thankfully, the usage follows the same rules as builtin
>>> functions, so they can be used in both the message form and
>>> paren-like fashion.  Doubling up might work, but it feels
>>> somehow "not right" to me.
>>> 
>>> 
>>> Rick
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Sep 18, 2014 at 12:49 PM, Mike Cowlishaw
>>> <[email protected]> wrote: If one didn't want to use up the
>>> 'gold' of single brackets  ...
>>> 
>>> 
>>> first, does one need the brackets at all?  I've often thought 
>>> as commas in Rexx as being a list notation, in effect, so 
>>> perhaps:
>>> 
>>> a=1, 2, 3
>>> 
>>> or
>>> 
>>> do x over 23, 34, 45
>>> 
>>> Or, to save single-square-brackets one could go 
>>> Wikipedia-like:
>>> 
>>> a=[[1, 2, 3]]
>>> 
>>> etc ...
>>> 
>>> Mike
>>> 



- -- 
Moritz Hoffmann; http://antiguru.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iF4EAREIAAYFAlQb98oACgkQ264ap80Va8e44QEAuoxtVmojKFICGFSBez+4t+kZ
MdmwRyAP/pUJxGUinWUA/Ar58W0zdzZJ82IxwVm+DOhvXI7mECOKkmJD9k0N38Hc
=ui8a
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to