Re: [fpc-pascal] some new features to delphi prisem
On 2/24/2010 2:48 AM, Matt Emson wrote: I think an interjection at this point is required - all of this is down to personal experience, preference and style. It is what you are used to. Having done 10+ years of Pascal, yes this is very alien. Having done 5+ years of C# and C based languages, no this is useful. Should it be part of Free Pascal? That is for the compiler maintainers to decide. However, don't write it off because you find it undesirable. One languages feature is another's bad syntax decision. I can't count the number of times I've tried to explain the point of Sets to non Pascal programmers (read: C based language users.) I also don't want to remember the countless bad implementations of Sets I saw whilst trying not to have to reinvent the wheel. Your post illustrates a misunderstanding that is common today - that choices are arbitrary and equivalent and should just be decided by personal preference. There are many choices people make today that are far more serious than that. But they just dismiss them as Its my choice. What's it to you? This is especially common in items of convenience. Within the philosophic principles that formed Pascal such a proposed construct is a violation. (As are some of the now accepted extensions introduced by Borland.) The principle is one of minimalism or conservation of features. The principle is: If a feature can be expressed using a reasonable expression of the current language features it is unnecessary and should be left out. Wirth did an outstanding job of adhering tot his principle. Those that followed him, not so much. It is important when considering language changes to observe the principles and adhere to them. Their logical consistency is important to maintain for that is is the basis of the language's integrity and that, in turn, is the basis of its elegance and power. -- Doug C. - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Hi!
Am Samstag, den 20.02.2010, 19:01 +0100 schrieb Jürgen Hestermann:
y := case Other of
bla : 'hello';
foo : 'bye';
baz : 'adius';
end;
What do you gain with this?
Doesn't look much different to
case Other of
bla : y := 'hello';
foo : y := 'bye';
baz : y := 'adius';
end;
You are looking at the wrong example! Clearly, for variable assignment
you don't gain anything. But for a function argument you do!
WriteLn('The value is ',(if X then 'true' else 'false'),
' at the moment.');
and
MakeBackup(FileName,ChangeExtension(FileName,
case BackupExtension of
exBak : '.bak';
exBkp : '.bkp';
exTilde : '~';
else '.bak'
End));
Bye
Hansi
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
You are looking at the wrong example! Clearly, for variable assignment
you don't gain anything. But for a function argument you do!
Realy?
WriteLn('The value is ',(if X then 'true' else 'false'),
' at the moment.');
Well, *this* can be done much easier ;-):
---
WriteLn('The value is ',X,' at the moment.');
---
But even if X is not boolean I would find that much more readable:
---
if X then s := 'true' else s := 'false',
WriteLn('The value is ',s,' at the moment.');
---
Even with the need of an intermediate variable (most of the time
you can reuse an existing variable) I would prefer this one over
the quite confusing nesting of case statement in an expression.
It states much clearer what happens.
MakeBackup(FileName,ChangeExtension(FileName,
case BackupExtension of
exBak : '.bak';
exBkp : '.bkp';
exTilde : '~';
else '.bak'
End));
Again, this would be much clearer code:
---
case BackupExtension of
exBak : s := '.bak';
exBkp : s := '.bkp';
exTilde : s := '~';
else s := '.bak'
End;
MakeBackup(FileName,ChangeExtension(FileName,s));
---
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Sent from my iPhone On 24 Feb 2010, at 06:10, Jürgen Hestermann juergen.hesterm...@gmx.de wrote: Well, *this* can be done much easier ;-): snip I think an interjection at this point is required - all of this is down to personal experience, preference and style. It is what you are used to. Having done 10+ years of Pascal, yes this is very alien. Having done 5+ years of C# and C based languages, no this is useful. Should it be part of Free Pascal? That is for the compiler maintainers to decide. However, don't write it off because you find it undesirable. One languages feature is another's bad syntax decision. I can't count the number of times I've tried to explain the point of Sets to non Pascal programmers (read: C based language users.) I also don't want to remember the countless bad implementations of Sets I saw whilst trying not to have to reinvent the wheel. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] some new features to delphi prisem
Sent from my iPhone On 21 Feb 2010, at 19:37, JoshyFun joshy...@gmail.com wrote: z := iff(a=b,1,2); But to me it looks awful and a bit of c-ism No, that is a VB-ism. A C-ism would be: z = (a==b ? 1 : 2); Which I fo tend to use myself in c# as it is a lot more convenient in some cases. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Graeme Geldenhuys wrote: Marco van de Voort wrote: It also proves that such solution external to the language is possible. That weakens the case for a language feature My point exactly! The language doesn't need such a feature because your editor of choice should be able to do that, and in Lazarus IDE that is the case. This is unrelated though. Refactoring has its place, but is absolutely specific to a single IDE. If one never intends to use that IDE, the functionality is gone. I don't care for the feature either, but I can also see why it would be desirable over mechanical string replacement, no matter how advanced. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Marco van de Voort wrote: IMHO Prism is not even Delphi. Just recycling of the brand. Laying cards on the proverbial table, I don't think it was ever intended to be Delphi. RemObjects developed the compiler completely outside of Delphi for a number of years before the technology was licensed to become Prism. Fact. IIRC, they billed Chrome (then Oxygen) as a Pascal-like syntax refined for the .Net framework. It was the Codegear/Embarcadero licensing that first created Delphi Prism. The syntax that Prism uses is a lot cleaner in many respects - especially removing the procedure/function conundrum and using instead method. However, in other ways it is horrible and so I can also see why it is not something worth discussing further. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
The syntax that Prism uses is a lot cleaner in many respects - especially removing the procedure/function conundrum and using instead method. However, in other ways it is horrible and so I can also see why it is not something worth discussing further. Matt, I am no Prism fan (I prefer native code). Having said that, would you care to explain the other ways in which it is horrible? Curious ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
On 22 Feb 2010, at 14:35, Anthony Walter wrote: The syntax that Prism uses is a lot cleaner in many respects - especially removing the procedure/function conundrum and using instead method. However, in other ways it is horrible and so I can also see why it is not something worth discussing further. I am no Prism fan (I prefer native code). Having said that, would you care to explain the other ways in which it is horrible? Maybe this discussion could be moved to the fpc-other list? It's not really directly applicable to FPC anymore. Thanks, Jonas FPC mailing lists admin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Jonas Maebe wrote: Maybe this discussion could be moved to the fpc-other list? It's not really directly applicable to FPC anymore. Indeed, which is why I said [..] I can also see why it is not something worth discussing further. I guess if someone was committing to developing the compiler mode switch for the dialect, it might be a different case. I sent a follow up before reading your email, so apologies and lips are now firmly zipped!! ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
In our previous episode, Matt Emson said: It also proves that such solution external to the language is possible. That weakens the case for a language feature My point exactly! The language doesn't need such a feature because your editor of choice should be able to do that, and in Lazarus IDE that is the case. This is unrelated though. Refactoring has its place, but is absolutely specific to a single IDE. No, there are multiple IDEs that support it to some extend or the other. XCode, Eclipse has had plugins in the past, Emacs (if you can find the editor in that OS) If one never intends to use that IDE, the functionality is gone. It's only important in ease of use and shorthand cases. If it really is functionality that is not doable otherwise, it's a different matter. Nobody will argue that a template that generates a wrapper around a container class is a substitute for generics. IOW, for this argument, the only advantage in favour must be shorthand, or other editing work related speedup of workflow. I don't care for the feature either, but I can also see why it would be desirable over mechanical string replacement, no matter how advanced. I don't believe in adding shorthands solely based on such reasons. THat is a carte blanche for all kinds of char twiddling non improvmeents. And in this case IMHO it is a specialisation of CASE, which is already an specialization of nested if then. If we implement that, we'll get the next level of specialization within the year probably, and probablyagain with similar argumentation ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
In our previous episode, Matt Emson said: Marco van de Voort wrote: IMHO Prism is not even Delphi. Just recycling of the brand. Laying cards on the proverbial table, I don't think it was ever intended to be Delphi. RemObjects developed the compiler completely outside of Delphi for a number of years before the technology was licensed to become Prism. Fact. IIRC, they billed Chrome (then Oxygen) as a Pascal-like syntax refined for the .Net framework. It was the Codegear/Embarcadero licensing that first created Delphi Prism. Correct. The syntax that Prism uses is a lot cleaner in many respects - especially removing the procedure/function conundrum and using instead method. However, in other ways it is horrible and so I can also see why it is not something worth discussing further. Good. I just want to add that not every improvement (even if a real consensus exists that it is better) is worth breaking compatibility for. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
On Sat 20 Feb 2010, Jürgen Hestermann wrote:
y := case Other of
bla : 'hello';
foo : 'bye';
baz : 'adius';
end;
What do you gain with this?
Doesn't look much different to
case Other of
bla : y := 'hello';
foo : y := 'bye';
baz : y := 'adius';
end;
or this...
type foo_type = (bla, foo, baz);
var foo_names : array [foo_type] of string = ('hello', 'bye', 'adius');
y := foo_names[other];
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
y := case Other of bla : 'hello'; foo : 'bye'; baz : 'adius'; end; What do you gain with this? Doesn't look much different to case Other of bla : y := 'hello'; foo : y := 'bye'; baz : y := 'adius'; end; Shorter write imho. Is that realy a reason for adding yet another extension to Pascal? This is C thinking. I don't care about a word more or less to write if only the *reading* of source code is easy (and the logic of the language is clear). But each variant in writing makes it harder to understand a source code (especially for newbies to whom the learning curve gets steeper and steeper with each of such 'extensions'). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
ik wrote: On Sat, Feb 20, 2010 at 20:01, Jürgen Hestermann juergen.hesterm...@gmx.de mailto:juergen.hesterm...@gmx.de wrote: y := case Other of bla : 'hello'; foo : 'bye'; baz : 'adius'; end; What do you gain with this? Doesn't look much different to case Other of bla : y := 'hello'; foo : y := 'bye'; baz : y := 'adius'; end; Shorter write imho. Which also means less chance of mistake. For example, if you decide later to change y to y1, you only have to change the code in one place, not three. Functional case and if are not only from Ruby, also from all functional languages (sml, ocaml), also Python and even C have functional if. I'm not saying that this is some revolutional or essential feature. But just because we can work without it doesn't mean it's totally useless :) Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Does this innovation makes case a function? procedure SomeProc(const v: string); SomeProc ( case Other of a: 'a'; b: 'b'; end; ); Imho, this reduces the code readability. thanks, dmitry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
In our previous episode, dmitry boyarintsev said: Does this innovation makes case a function? I'd rather say an expression. procedure SomeProc(const v: string); SomeProc ( case Other of a: 'a'; b: 'b'; end; ); Imho, this reduces the code readability. Even if you are a favorite of said functionality, it should not be added adhoc, but integrated in the language definition. (but that would mean it is no longer Pascal). I don't see the use either. Moreover the benefit/cost (work) is way to high IMHO ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
On 21 February 2010 17:00, Michalis Kamburelis michalis.ka...@gmail.com wrote: Which also means less chance of mistake. For example, if you decide later to change y to y1, you only have to change the code in one place, not three. Unfortunately you are wrong Michalis. Ever heard of 'syncron-edit'? http://wiki.freepascal.org/New_IDE_features_since#Syncron-Edit You only need to change one variable, and all other instances will change to. And syncron-edit applies to any selection of text. So already works in more cases. I vote against adding this language feature. It's not pascal-like and actually makes the code harder to read. It also only applies to simple assignment. Case begin..end blocks can do much more than simple oneliners. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
On Sun, Feb 21, 2010 at 9:03 PM, Graeme Geldenhuys graemeg.li...@gmail.com wrote: I vote against adding this language feature. It's not pascal-like and actually makes the code harder to read. It also only applies to simple assignment. Case begin..end blocks can do much more than simple oneliners. Maybe some-one would like to catch-up with Delphi/Prism? Wouldn't be possible to start a Prism mode to support new Delphi syntax features? (or modeswitch, just like objectivec)? I don't volunteer :) I'm happy with the present FPC syntax. thanks, dmitry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
In our previous episode, dmitry boyarintsev said: assignment. Case begin..end blocks can do much more than simple oneliners. Maybe some-one would like to catch-up with Delphi/Prism? Wouldn't be possible to start a Prism mode to support new Delphi syntax features? (or modeswitch, just like objectivec)? IMHO Prism is not even Delphi. Just recycling of the brand. I'd rather see the time spent on features that really matter (like generics, SEH/COM support, unicode). If a feature is not supported by delphi, the usage is usually very low (since most people don't even know about it, and some are limited by compatibility requirements), except in the rare cases that it is really used a lot (like in the past the pointer overindexing and the exit() features. But they are no longer extensions, since D2009 Delphi has them too) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
On Sun, Feb 21, 2010 at 9:22 PM, Marco van de Voort mar...@stack.nl wrote: I'd rather see the time spent on features that really matter (like generics, SEH/COM support, unicode). +1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Graeme Geldenhuys wrote: On 21 February 2010 17:00, Michalis Kamburelis michalis.ka...@gmail.com wrote: Which also means less chance of mistake. For example, if you decide later to change y to y1, you only have to change the code in one place, not three. Unfortunately you are wrong Michalis. Ever heard of 'syncron-edit'? http://wiki.freepascal.org/New_IDE_features_since#Syncron-Edit You only need to change one variable, and all other instances will change to. And syncron-edit applies to any selection of text. So already works in more cases. Which is cool, but only if you and all your contributors use Lazarus for all your editing. The fact that Lazarus makes something easier should not be a reason to reject the language feature. I vote against adding this language feature. It's not pascal-like and actually makes the code harder to read. It also only applies to simple assignment. Case begin..end blocks can do much more than simple oneliners. This is a matter of taste, I can imagine uses when at least functional if would make code *more* readable. Noone forces programmers to convert all their case/if to functional versions if they look unreadable. The functional variants are supposed to be used in particular situations, when they make sense. Mind you, I'm not saying I'm a fan or a big proponent of this feature. I do not own Delphi since a long time, being happy with FPC, so I'm also not interested in compatibility. Mostly, I'm playing devil's advocate here :), and I didn't see yet a good argument against this feature (and I see cases when it would be useful). The fact that it makes some cases less readable doesn't count here imho (because it's optional, and can make other code more readable). Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
In our previous episode, Michalis Kamburelis said: You only need to change one variable, and all other instances will change to. And syncron-edit applies to any selection of text. So already works in more cases. Which is cool, but only if you and all your contributors use Lazarus for all your editing. The fact that Lazarus makes something easier should not be a reason to reject the language feature. It also proves that such solution external to the language is possible. That weakens the case for a language feature This is a matter of taste, I can imagine uses when at least functional if would make code *more* readable. Noone forces programmers to convert all their case/if to functional versions if they look unreadable. The functional variants are supposed to be used in particular situations, when they make sense. That is always the reason, but every feature must be implemented tested, supported, and may clash with future extensions. it wouldn't hurt, and a bit of typing, and some fairly theoretic case about readability are IMHO quite weak arguments. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] some new features to delphi prisem
Hello FPC-Pascal, Sunday, February 21, 2010, 7:29:54 PM, you wrote: MK This is a matter of taste, I can imagine uses when at least functional MK if would make code *more* readable. Noone forces programmers to MK convert all their case/if to functional versions if they look MK unreadable. The functional variants are supposed to be used in MK particular situations, when they make sense. For me the bigger problem is that both statements change its behavior in function of its context. if a=b then 1 else 2; this is a pascal error, but z := if a=b then 1 else 2; Is it correct ? From my point of view is much more reasonable to use something like: z := iff(a=b,1,2); But to me it looks awful and a bit of c-ism and really horrible code could be written: z: Boolean; begin z := iff(a=b,iif(b=2,a=b,ba),not(a=b)); -- Best regards, JoshyFun ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
On Sun, 21 Feb 2010 20:37:12 +0100, JoshyFun wrote about Re[2]: [fpc-pascal] some new features to delphi prisem: Sunday, February 21, 2010, 7:29:54 PM, you wrote: MK This is a matter of taste, I can imagine uses when at least MK functional if would make code *more* readable. Noone forces MK programmers to convert all their case/if to functional versions MK if they look unreadable. The functional variants are supposed to MK be used in particular situations, when they make sense. For me the bigger problem is that both statements change its behavior in function of its context. if a=b then 1 else 2; That is an attempt at a statement, but what is being offered in Prism is an enhanced *expression* syntax. this is a pascal error, but z := if a=b then 1 else 2; This is actually valid ALGOL 60 and/or ALGOL 68. Conditional expressions were available in both languages. I think Niklaus Wirth continued with this in ALGOL W, but dropped it from Pascal. Note that the ALGOLs required the else clause, as does C today (see below). Is it correct ? From my point of view is much more reasonable to use something like: z := iff(a=b,1,2); This is over-punctuated Visual BASIC. Yuck. But to me it looks awful and a bit of c-ism and really horrible code could be written: z: Boolean; begin z := iff(a=b,iif(b=2,a=b,ba),not(a=b)); Mega-yuck!! I can only infer that you don't write C. The C equivalent is: z = a == b ? 1 : 2; It's terse, but one gets used to it. -- Regards, Dave [RLU #314465] === david.w.n...@ntlworld.com (David W Noon) === ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] some new features to delphi prisem
Hello FPC-Pascal,
Sunday, February 21, 2010, 9:32:50 PM, you wrote:
DWN This is actually valid ALGOL 60 and/or ALGOL 68. Conditional
DWN expressions were available in both languages. I think Niklaus Wirth
DWN continued with this in ALGOL W, but dropped it from Pascal.
DWN Note that the ALGOLs required the else clause, as does C today (see
DWN below).
I'm the opposite of an compilers expert, also never learned Algol,
modula, eiffel or non main-stream languages, except Forth. So I
known my opinion is not an expert opinion, just an opinion only.
After this preamble :) I must say that this is Pascal, not Algol ;)
Is it correct ? From my point of view is much more reasonable to use
something like:
z := iff(a=b,1,2);
DWN This is over-punctuated Visual BASIC. Yuck.
iff is valid in VB ? Just a coincidence, I was trying to note the
if-function.
But to me it looks awful and a bit of c-ism and really horrible code
could be written:
z: Boolean;
begin
z := iff(a=b,iif(b=2,a=b,ba),not(a=b));
DWN Mega-yuck!!
I even do not know the result :)
DWN I can only infer that you don't write C. The C equivalent is:
Oh yes, I write and wrote C/C++ that's the reason I hate such things,
like:
if (a=a++==a) {..}
It's a funny entertainment to try to know which exactly that condition
will execute.
DWNz = a == b ? 1 : 2;
DWN It's terse, but one gets used to it.
In near 20 years I was unable to find the reason and need of such
constructions, even when my first computer only have 3 Kb for source
code.
--
Best regards,
JoshyFun
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Marco van de Voort wrote: IMHO Prism is not even Delphi. Just recycling of the brand. +1 I'd rather see the time spent on features that really matter (like generics, SEH/COM support, unicode). Definitely. I would like to add 'Interface Delegation' to that list. It's a vital part of Interfaces that is not implemented in FPC yet. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Marco van de Voort wrote: It also proves that such solution external to the language is possible. That weakens the case for a language feature My point exactly! The language doesn't need such a feature because your editor of choice should be able to do that, and in Lazarus IDE that is the case. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] some new features to delphi prisem
Hello, REM Objects released an interesting document regarding some changes (that looks so much like Ruby) to their Delphi Prisem. For example assignment of a value regarding a condition: x := if Something then 2; y := case Other of bla : 'hello'; foo : 'bye'; baz : 'adius'; end; And more. You can find more in http://blogs.remobjects.com/blogs/mh/2010/02/18/p1116 Ido http://ik.homelinux.org/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
y := case Other of bla : 'hello'; foo : 'bye'; baz : 'adius'; end; What do you gain with this? Doesn't look much different to case Other of bla : y := 'hello'; foo : y := 'bye'; baz : y := 'adius'; end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
On Sat, Feb 20, 2010 at 20:01, Jürgen Hestermann juergen.hesterm...@gmx.dewrote: y := case Other of bla : 'hello'; foo : 'bye'; baz : 'adius'; end; What do you gain with this? Doesn't look much different to case Other of bla : y := 'hello'; foo : y := 'bye'; baz : y := 'adius'; end; Shorter write imho. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
In our previous episode, ik said: Shorter write imho. Or something easily marketable to make people upgrade. Not a problem of FPC. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
