They were removed from the language because in practice, they resulted in
lots of problems when a closing delimiter was accidentally omitted. It was
pretty easy for a missing quote to swallow up large sections of the program
without error.
I'm not particularly in favor of adding this.
Rick
On Fri, Oct 14, 2016 at 4:37 PM, Erich Steinböck <erich.steinbo...@gmail.com
> wrote:
> I had a look at the REX folder which mfc has provided at
> http://speleotrove.com/rexxhist/rexcard-208-scan.pdf and saw that we had
> multi-line strings already back in 1980. So I'd like to reopen the
> discussion about adding multi-line literals. (This is not imbedded data -
> now available through the ::RESOURCE directive in 5.0 - but inlined
> literals.)
>
> At first, what was the reason we lost multi-line strings (starting with a
> simple quote, and spanning multiple lines)?
>
> What about re-introducing them, either with a third type of quote (e. g. `
> ) or some double-character quote (e. g. `" multi - line string "` )
>
>
>
> On Sat, Jun 14, 2014 at 6:32 PM, Rick McGuire <object.r...@gmail.com>
> wrote:
>
>> I do for see a use for multi-literals, but I don't really see them as
>> being a good usage for the type of problem I'm trying to solve here. The
>> directive approach is really intended for situations where I really wish to
>> embed a file within a single source program rather than having it
>> elsewhere. I most definitely do not want all of that date plunked in the
>> middle of logic, particularly if it is quite large. Additionally, the
>> directive approach means that data is available to other sections of the
>> code, not just in the context where it happens to be coded. Additionally,
>> since I envision this data being obtained from the package directive, it
>> can be made public, which means other consumers of that code can obtain
>> access to the data.
>>
>> I'm not adverse to multi-line literals...in fact, they would be quite
>> useful for things like dynamically defining methods or embedding snippets
>> of XML code, but can we separate the discussions of these two features,
>> since they really solve different problems.
>>
>> Rick
>>
>>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
