Nick Hodges

New Language Construct for Exit

22 Jul

In Tiburon, the following two functions do exactly the same thing:


function DoSomething(aInteger: integer): string;
begin
  if aInteger < 0 then
  begin
    Exit('Negative');
  end;
  Result := 'Positive';
end;

function DoSomething(aInteger: integer): string;
begin
  if aInteger < 0 then
  begin
    Result := 'Negative';
    Exit;
  end;
  Result := 'Positive';
end;

Share This | Email this page to a friend

This entry was posted on Tuesday, July 22nd, 2008 at 1:40 pm and is filed under Delphi. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

61 Responses to “New Language Construct for Exit”

1
Andreas Hausladen Says:

Finally we get this feature that other languages had from their beginning on.
July 22nd, 2008 at 2:04 pm
2
Nick Hodges Says:

Andreas –

You’re welcome!

Nick
July 22nd, 2008 at 2:20 pm
3
Jan Derk Says:

Great feature. It really starts showing that you guys aren’t wasting all your time on .NET anymore.

I am almost going to expect that you are going to tell us next that you ditched the Visual Studio 1 Gigabyte help viewer, that the silly product activation is gone, that the Together .NET bloatware is ditched and that Delphi 2009 installs in 10 minutes instead of hours.
July 22nd, 2008 at 2:32 pm
4
Mervin Yan Says:

So we don’t need specify the return type, ’string’ for your example, right?
July 22nd, 2008 at 2:34 pm
5
Giel Says:

That’s sweet. I’ve been wanting that for quite some time.
July 22nd, 2008 at 2:36 pm
6
James Nagle Says:

Nice, I can’t wait
July 22nd, 2008 at 2:37 pm
7
Nick Hodges Says:

Giel –

Not sure what you are asking — but the Exit function will always expect the parameter to be the same type as the Result would be.

Nick
July 22nd, 2008 at 2:46 pm
8
Osama ALASSIRY Says:

Would be a much nicer-looking example if you omitted Begin/End in the 1st example
July 22nd, 2008 at 2:49 pm
9
El Cy Says:

A very nice addition ! Congrats for such small but powerful additions.

Any chance to have also support for multicast events in Win32 similar to VCL.NET using Include(event, handler)/Exclude(event, handler) functionality ? I think this will be more than welcomed !

Regarding anonymous methods: are these also allowed "for objects" or are just anonymous functions & procedures but not "methods" (bound to objects) ?

How about using anonymous methods as "inline listeners" ?

ex:

var
anonListener: reference to procedure(Sender: TObject) of object;
….

anonListener := procedure(Sender: TObject) begin ShowMessage(’Handled by an anmeth !’); end;
button1.OnClick := anonListener;

Question 1:
It will be the above form allowed ?
Question 2:
How about this more "inlined" (see closure support in other modern languages) variation ?

procedure(Sender: TObject) begin ShowMessage(’Handled by an anmeth !’); end;

Question 1:

….

With multicast support we can have something like this:
July 22nd, 2008 at 2:52 pm
10
El Cy Says:

A very nice addition ! Congrats for such & similar small but powerful additions.

Any chance to have also support for multicast events in Win32 similar to VCL.NET using Include(event, handler)/Exclude(event, handler) functionality ? I think this will be more than welcomed !

Regarding anonymous methods: are these also allowed "for objects" or are just "anonymous functions & procedures" but not "methods" (bound to objects) ?

How about using anonymous methods as "inline listeners" ?

var
anonListener: reference to procedure(Sender: TObject) of object;
….

anonListener := procedure(Sender: TObject) begin ShowMessage(’Handled by an anmeth !’); end;
button1.OnClick := anonListener;

Question 1:
It will be the above syntax allowed ?
Question 2:
How about a more "inlined" (see closure support in other modern languages) variation bellow ?

button1.OnClick := procedure(Sender: TObject) begin ShowMessage(’Handled by an anmeth !’); end;

Question/Suggestion 3:

With multicast events + inlined definition support we can have something like this:

Include(button1.OnClick, procedure(Sender: TObject) begin ShowMessage(’Handled by an anmeth - 1 !’); end;);
Include(button1.OnClick, procedure(Sender: TObject) begin ShowMessage(’Handled by an anmeth - 2 !’); end; );

Any comments on these ?

10x for your great commitment on Delphi … And regarding Tiburon I’m almost finding myself reloading again & again my Delphi related feeds to discover the new goodies … so please keep your (all team + field testers) Tiburon mood opened for sharing ….

And don’t forget your promise of new "Camtasias" … Tiburon is a very good occasion to resume your videos introducing new Delphi features + tips & tricks.
July 22nd, 2008 at 3:02 pm
11
Nick Hodges Says:

El Cy –

Sorry, no multi-cast delegates this time around. Definitely high on the list, though.

As for anonymous methods, I’ll have to defer to our compiler guys, who will hopefully be blogging about them more. I’m not smart enough on them to answer things at that level of detail.

Nick
July 22nd, 2008 at 3:02 pm
12
Clinton Johnson Says:

I like - very nice. Any chance the next version of Delphi can get the ?: functionality of C?

something like:

Caption := Format(’Copied %d file%s’,[Count,if Count=1 then 's' else '']);

A sort of an "if function". Many of us used bastardized overloaded operators to do similar things, but it always feels like a kludge… Ya I know, keep using the overloads, but a guy can dream.
July 22nd, 2008 at 3:11 pm
13
Alexandre Machado Says:

Nice Nick! A simple missed thing that makes difference
July 22nd, 2008 at 4:06 pm
14
Anthony Frazier Says:

Fina-fricking-ly.

Thank you!
July 22nd, 2008 at 4:17 pm
15
Tom Birch Says:

I wish we had the following construct

try
except
on S:SomeOtherException do;
on E:Exception do ;
finally
end

instead of
try
try
except
on S:SomeOtherException do;
on E:Exception do ;
end
finally
end
July 22nd, 2008 at 4:24 pm
16
Jolyon Smith Says:

@El Cyd

You can roll your own multi-cast events (or ask nicely and I’ll share mine). These do not need language support, per se, and can have additional benefits over the C# implementation.

The only thing that is difficult is design-time support for them, but this - so far for me at least - is a technical challenge that has yet to encounter a compelling requirement imperative.

Oh, and EXIT(value)… great stuff. It’s going to be hard to break almost 15 years of habit though.

What a pity we’ve had to wait so long for trivial but useful things like this. It must have taken someone almost an hour to implement this, assuming they stopped for a leisurely lunch in the process.
July 22nd, 2008 at 4:50 pm
17
JB Says:

I can’t believe nobody mentioned how disappointed they are you haven’t fixed the with statement yet…

Anyway, hooray for the new Exit parameter! Nice touch…
July 22nd, 2008 at 6:54 pm
18
Richard Foersom Says:

Good that you are updating the language, but additional features to encourage use of exit in the middle of a function - no need, thanks.

For non trivial functions, exit in the middle of function leads to code bloat and maintenance problems.

Example:
(/LessThan/ should be the less-than symbol but the comment system do not allow that)

function DoSomething(aInteger: integer): string;
begin
if aInteger /LessThan/ 0 then
begin
Action1;
Exit(’Negative’);
end
else if aInteger = 0 then
begin
Action2;
Exit(’Zero’);
end;
Action3;
Result := ‘Positive’;
end;

Later, due to the actions in Action1, Action2 and Action3 it becomes necessary to add a semaphore on this:

function DoSomething(aInteger: integer): string;
begin
Pend(ActionSem);
if aInteger /LessThan/ 0 then
begin
Action1;
Post(ActionSem);
Exit(’Negative’);
end
else if aInteger = 0 then
begin
Action2;
Post(ActionSem);
Exit(’Zero’);
end;
Action3;
Post(ActionSem);
Result := ‘Positive’;
end;

Not great, what should have been a simple one lock, one unlock in the function, requires duplication of unlock calls - code bloat.

If you are not used to use semaphores, think of the example as handling of a global ressource, e.g. open/close file or allocation/freeing memory.

The second problem with the multi exit is that this has no clarity on the lock handling. Likely during the addition of the semaphore one of the exit paths (e.g. for Zero) is forgotten, so in the special case of Zero the semaphore is not unlocked. Result is that that mostly it works OK, but in some rare cases the code freeze waiting on the semaphore. Good luck tracking that down.

Really, the use of the exit function should rather be discouraged.

Doei RIF
July 22nd, 2008 at 7:38 pm
19
Richard Foersom Says:

@Clinton Johnson

What about using the ifthen() function?

http://delphi.about.com/library/rtl/blrtlIfThen.htm

Actually this function should rather have been called IfThenElse.
July 22nd, 2008 at 7:45 pm
20
Tobias Giesen Says:

Richard,

even in the most simple cases, lock/unlock pairs should be used like this:
Lock;
try
DoStuff;
finally
Unlock;
end;

Even if DoStuff is so simple it can never throw an exception, try-finally is obligatory. And then the Exit is no longer a problem.
July 22nd, 2008 at 8:19 pm
21
Richard Foersom Says:

@Tobias

Yes, that is a good method. The whole point is to avoid starting to use exit.
July 22nd, 2008 at 8:53 pm
22
Clinton Johnson Says:

@Tobias -> Ya, I have a whole set of IfOp calls that do exactly the same thing. I have found that the process is somewhat limited in what it supports (after all, it can only support what has been overloaded, but that isn’t the whole limit of what is possible, such as record assignments)

Something built into the language would almost always be more efficient and flexible.

Which reminds me, gotta go make sure my IfOp calls are defined for inline…
July 22nd, 2008 at 9:32 pm
23
Sebastian P.R. Gingter Says:

I once postet a small sample in the german Delphi-PRAXiS on how one can build his own multicast delegate thing. Let’s call it a ‘Event Distributor’:

http://www.delphipraxis.net/post616915.html#616915

Well, it’s actually not really beautiful. But if you really need it, then it’s no more than about 40 lines away.
July 22nd, 2008 at 9:33 pm
24
Thomas Mueller Says:

Nice to see finally a feature we already had with Andreas Hausladen’s dlangextensions making it into the compiler. Now, if only the others like multiline strings, case with strings and file macros also made it …
(Yes, I am ungrateful. )

twm
July 22nd, 2008 at 11:01 pm
25
Oliver Giesen Says:

@Richard Foersom and others:

The main problem with the IfThen function apart from the need for overloads for every conceivable data type IMO is that both the True and the False argument have to be evaluated even though only one will be needed. The benefit of a language construct for this would be that the condition argument would be evaluated first and then only the relevant one of the two remaining ones would get evaluated.

Example:

ShowMessage(’Sender is ‘ + IfThen(Assigned(Sender), Sender.Name, ‘nil’));

This is currently not possible but it would be really great if it was. I had hoped that this could be solved by inlining the IfThen function but it doesn’t.

Oliver
July 22nd, 2008 at 11:37 pm
26
El Cy Says:

1) Build-in support for multicast events/delegates for Delphi/Win32 (using Include/Exclude as in VCL.NET) will avoid using any artificial/limited approach but will simply register a generic dispatcher for the OnXXX event property …
Having something like this: Include(OnXXXEvent, myHandler) & Exclude(OnXXXEvent, myHandler); (without any other cumbersome "add", "remove" special property markings) will be more then welcomed, since this should be very portable and supported by any events, not just by special (add, remove) "marked" ones.
If the special handling of add/remove will be needed then the "add", "remove" make sense, otherwise the compiler should "inject" the generic event dispatcher into the OnXXX event.
This approach will support both current single-delegate and multiple-delegates.
1) object.OnXXXXEvent := mySimpleHandler; will assign the delegate so the previous one (if a multicast) will be disposed
2) Include(object.OnXXXXEvent, myMultiHandler); will create the delegate dispatcher and register into it both the "mySimpleHandler" previously registered using regular assignment and also the "myMultiHandler" (newly included)

Adding support for operator overloading to Delphi.Win32 will let use C# similar constructs for registration/unregistration of handlers.

myObject.OnXXXEvent := myObject.OnXXXEvent + myHandler;
myObject.OnXXXEvent := myObject.OnXXXEvent - myHandler;

@Jolyon Smith - could you share/post a link with your event-multicast implementation ?
I was fighting with creating something similar but very general (using RTTI + TMethod) but had no success so far :(… The general problem in this case was not the registration/un-registration of delegates/handles but the invocation of the handlers with unknown number/type of parameters (maybe a BASM wrapper will help in this case).
Additioally using something like: "Include(, )" will create problems since initially "" will be "nil" (so no RTTI there) … so it is obvious that we will need compiler support (RTTI is not enought in this case).

Maybe CodeGear could come with a general wrapper for multicast events (until this will be nativelly supported).

2) Build-in support for inlined IF (IIF, ?: like function) will make possible to avoid all parameter evaluation as the usual/ordinary "IfThen", "IIF" functions and instead get the right value (according to the boolean condition fast evaluation) without any side effects.
July 23rd, 2008 at 12:00 am
27
Kryvich Says:

Nick,
it’s great addition, thanks!

But I like it more:

function DoSomething(aInteger: integer): string;
begin
Exit(if aInteger _less_then_ 0 then ‘Negative’ else ‘Positive’);
end;
July 23rd, 2008 at 12:50 am
28
m. Th. Says:

@Nick:

Great feature! Thanks! Btw, speaking about Andreas Hausladen, "Case statement for strings/non-ordinal data types" sounds familiar? (ref.: QC #610 submitted 6 (six) years ago)

@All interested in ‘?:’, ‘IfThen’, inlined ‘IIF’ etc. (including Nick )

Having a ternary operator it would be a very nice feature, of course, - see the ol’ report QC #8451 with a similar discussion in comments (just only a little more ‘heated’ than there ;-)), but imho having a lazy parameter evaluation (QC #63483) would give a much broader feature coverage. And also, a ternary operator (the ‘Elvis’ operator ?: ) can be easily built on top of it.

Nick & others: what do you say?

(Just my 2c & HTH)
July 23rd, 2008 at 1:05 am
29
HardOrc Says:

if aren’t free version of Delphi Tiburón (like Turbo explorer edition) I will go to make suicide :///
July 23rd, 2008 at 2:30 am
30
Richard Foersom Says:

@Oliver Giesen
OK, indeed it would more useful with a real language construct IfThenElse() which only evaluate the needed part.
July 23rd, 2008 at 3:24 am
31
Mike P Says:

it’s a wonderful construct i have wished for for a long time. thank you!

(a ternary operator would be useful as well.)
July 23rd, 2008 at 6:31 am
32
Clinton Johnson Says:

@Oliver -> Good catch. That bit me in the butt just last week in fact.

@Richard Foersom

Try/Finally is your friend. Exit falls through the finally blocks, so you can code like this :

function DoSomething(aInteger: integer): string;
begin
Pend(ActionSem);
try
if aInteger /LessThan/ 0 then
begin
Action1;
Exit(’Negative’);
end else if aInteger = 0 then
begin
Action2;
Exit(’Zero’);
end;
Action3;
finally
Post(ActionSem);
end;
Result := ‘Positive’;
end;

instead of:

function DoSomething(aInteger: integer): string;
begin
Pend(ActionSem);
if aInteger /LessThan/ 0 then
begin
Action1;
Post(ActionSem);
Exit(’Negative’);
end
else if aInteger = 0 then
begin
Action2;
Post(ActionSem);
Exit(’Zero’);
end;
Action3;
Post(ActionSem);
Result := ‘Positive’;
end;
July 23rd, 2008 at 7:35 am
33
bart roozendaal Says:

Hi Nick, no disrespect, but I don’t get it why most people here are showing something close to euphoria. Sure, nice little feature, but hardly earth shattering news. I can imagine there are better things to report about Tiburon (or at least I hope). I don’t see the enormous value in this, just a little help for ‘lazy’ programmers. Sorry…
July 23rd, 2008 at 7:41 am
34
Giel Says:

Bart,

I think that’s because we all understand this one, while most of us are still struggling with the anonymous methods and unicode stuff
July 23rd, 2008 at 9:47 am
35
Andriy Gerasika Says:

Hi,
any chance on getting synchronized feature from Java?

for example, the simplest case:
type
Tobj = class
public
procedure A; synchronized;
procedure B; synchronized;
end;

Thanks,
Andriy
July 23rd, 2008 at 3:53 pm
36
Sip from the Firehose : Tiburon - new language features for Delphi 2009 Says:

[...] For a look at the new language construct for Exit, check out Nick Hodges blog at http://blogs.codegear.com/nickhodges/2008/07/22/39079/ [...]
July 23rd, 2008 at 4:38 pm
37
Clinton Johnson Says:

Bart -> The object pascal language from Borland/CodeGear/Embacawhatsit has been slow to evolve. Those of us who have been around since the turbo pascal days like to see any sign that the language will move foward and evolve to remain significant. It might be a small feature, but its a part of a larger pattern we like to see happen.

Besides, it does make the code a little easier to write and follow.

Still hoping for Linq before 2020 tho…
July 23rd, 2008 at 4:41 pm
38
Maxim Says:

return statement is great but it’s just
Result:= …; Exit;
syntactic sugar.

As for multicast events I would look into some late-binding framework like Spring in Java. Basically you write your objects/components and describe to the framework how to link calls between them in a separate XML file. It allows for much greater flexibility and avoid tight coupling between componenets. As an additional benefite you get AOP features as well. For me multicast delegates are the half-way. But late-binding would require extended and simpler-to-use RTTI.

The second valuable feature would be property-change notifiers/triggers or direct routers like

myObject1.Prop1
July 23rd, 2008 at 9:23 pm
39
Maxim Says:

myObject1.Prop1
July 23rd, 2008 at 9:26 pm
40
El Cy Says:

@Maxim
Why add the complexity of Spring for "simple" stuff as multicast-events that should be supported natively in Delphi ?

Spring is heavily based on Java reflection and proxies (that SFAIK we are missing in Delphi) + event listeners (in this context)… so in the Delphi case this might happen with proper native and RTTI support that should be added to the language (see my suggested examples/syntax above)

The first step for multicast-events in Delphi/Win32 will be to add/introduce a way (by compiler means) to easily use/hide a dispatcher (that will manage the list of delegates) as a simple delegate/event handler (so supporting current syntax) and to add the proper syntax (Include/Exclude or/and operator overloading := +, := -) to register/unregister the events.
Of course this feature have to be typesafe (to allow just the propper delegates to be registered for an event) and also might be somehow exposed into the RTTI so the various wrappers could

As for the proxy support we can count on dynamic support already existing in Delphi (Variant + invocation: see Marco Cantu’s articles on DSLs) but we can’t generate the code on the fly since on the platforms (Java, .NET, dyn lang) that support this feature this is provided by the underlying VM and class loading mechanism.

Since all of these are not quite trivial we can not expect such additions (or like LINQ) in Delphi in short time .. so better pressure CG/EC to focus on stability and add simple and productive features like the extended "Exit" and possible IIF/ternary operator….
July 23rd, 2008 at 10:42 pm
41
Clinton Johnson Says:

@Maxim -> "Syntatic sugar" how is that a bad thing? 99% of the differences between Delphi and basic Wirth pascal are all Syntatic sugar, but look what you can create with them.

People throw that phrase around like it is suppose to mean something bad. All it means is "making your life easier by doing more with less". Heck, if you want to get right down to it, multiplication is syntatic sugar. After all, you can do the same thing with shifts and additions. Easier to just multiply tho.

Just remember that larger features are built on smaller features. Heck most of Linq is based on anonymous calls and type inference (would love to see that in Delphi one day soon, along with inline variable declaration - certainly should not be a difficult task for a top down compiler!) and a bit more sytnatic sugar. And the power Linq offers to simplify data management and processing code can’t be denied. Syntatic sugar is your friend.
July 24th, 2008 at 12:40 am
42
Christian Wimmer Says:

What an accident! I suggested this feature at the Delphi Days in Günzburg to David I.
July 24th, 2008 at 3:05 am
43
AL_one Says:

And what about assignment operation that returns the value. I dream of writing code like this:

//—
while (Obj := FindNext) nil do
Process(Obj);
//—

insted of:

//—
Obj := FindNext;
while Obj nil do
begin
Process(Obj);
Obj := FindNext;
end;
//—
July 24th, 2008 at 3:29 am
44
AL_one Says:

Sorry, "not equal" sign before nil’s disappeared
July 24th, 2008 at 3:32 am
45
Bobfrank Says:

@Clinton Johnson:

(would love to see that in Delphi one day soon, along with inline variable declaration - certainly should not be a difficult task for a top down compiler!)

Oh please, don’t even joke about that. Trying to debug other people’s open-source components is bad enough already. Allowing people to declare variables wherever they felt like would turn it from a nuisance to an absolute horror.

If we wanted to deal with that sort of crap syntax, we’d use C.
July 24th, 2008 at 4:59 am
46
Clinton Johnson Says:

Bobfrank -> I have seen some mighty bad "other people’s code" open source and otherwise. I don’t see inline variable declaration as that much worse of a problem.

Any tool can be abused, and someone will find a way to abuse it worse than you ever dreamed possible. I suppose, however, if done properly, type inference does not absolutely require inline variable declaration.

Var
x : infered;

Begin
X := ‘Howdy’;
Writeln(X);
End;

would work just as well and avoid inline variable declaration (I could still stand to see loops allow as part of the loop declaration tho - limited scope and all).
July 24th, 2008 at 9:12 am
47
Bobfrank Says:

Even so, what’s the benefit to it? I find it’s really useful to declare my array indices at the top; I frequently write routines with several sequential (non-nested) FOR loops in them, and so it’s a simple matter to just declare one I: integer and use it for each loop. The compiler warnings take care of the scope issue for you.

What really worries me about inline variable declarations is the possibility of someone declaring an object or other dynamically-allocated memory in the middle of a big, long, complicated subroutine and then forgetting to free it. I’ve seen this done in C/C++ code, and having to hunt through two pages of syntactical diarrhea to track down a memory leak that could have been streamlined if the moron had just declared his objects at the top of the procedure like a civilized coder is just not my idea of a good time, y’know?
July 24th, 2008 at 9:58 am
48
George Says:

AL_one Says:

"And what about assignment operation that returns the value."

No, thanks. Use C++ for that.
July 24th, 2008 at 10:42 am
49
Clinton Johnson Says:

@Bobfrank -> Where you declare your variable will not help that. Using a Try/Finally right after you create the object will. If the code is really complicated (aside from the possibility that you’ve made some poor design choices), the variable declarations can be so far removed from related code to be pretty much meaningless.

@George -> I was gonna vote in on that one, but its bit me in the ass a few times in C, so I’ve decided I’m not gonna touch that with a 10 foot pole - probably best without it in the long run for the few times I wished I had it in Delphi.
July 24th, 2008 at 4:26 pm
50
Bobfrank Says:

Where you declare your variable will not help that. Using a Try/Finally right after you create the object will.

It helps quite a bit. It lets me know right off the bat that the variable exists in this routine, instead of me having to pick through a few pages of code line-by-line to verify that. Remember, I’m talking about debugging other peoples’ code here. I already use try blocks extensively in my own work. (Maybe even too much.)

I have to know what someone’s trying to do before I go trying to fix it, and most of the stuff I’ve ended up having to pick through hasn’t been commented particularly well (or at all), so it ends up coming down to UTSL. And the less opportunities some "clever" coder has to do stupid things like hide a large object declaration on the 73rd line of a 212-line routine, the better for everyone else involved.
July 24th, 2008 at 6:16 pm
51
Bobfrank Says:

Addendum (I wish there was an Edit button for comments)

When I say that it’s useful to know whether a variable exists in a certain routine, I mean being declared there, as opposed to being used but declared at some higher level of scope. Since there are no strict rules on identifier names, it can be difficult. How do you know if "NewFilename" is part of this function, a property of the current object, a global variable, or a function in some other unit that doesn’t take any arguments?
July 24th, 2008 at 6:21 pm
52
Hansi Says:

Yeah, and it’s even compatible with FreePascal! First time Borland/CodeGear did _not_ introduce an intentional incompatibility!

Bye
Hansi
July 24th, 2008 at 10:57 pm
53
Nick Hodges Says:

Hansi –

We’ve never purposefully put an incompatibility with FreePascal.

Nick
July 25th, 2008 at 8:15 am
54
J Doll Says:

Why is that a powerful feature? It just seems to be laziness me, too save one extra line. I would assume the code the compiler produces is no different.
July 25th, 2008 at 5:06 pm
55
Zigmund Bulinsh Says:

Save god Delphi 2009, do not implement multicast events! It must be implemented by developer and it is school level task (at Least in USSR). But if there are some dull guys who cant implement this and hope to language enchancements - they need their brain enchancements, not language!

Thanks Nick for your good work! Keep it going the same way. Adn do not go the same way as C# or other shit languages goes. Delphi must be strict like it always was!!! And no drunk programmers with their C# or C++ features (my own opinion, of course. No comments on this).

Make it simpe as possible, but not more!!! (Nicklaus Wirth)
August 1st, 2008 at 12:25 am
56
Al González Says:

Nick, great, but why not "Return Value;" instead "Exit (Value);"?

"Return Value;", like in C language, is more easy.

Al Gonzalez.
August 1st, 2008 at 8:56 am
57
Maël Hörz Says:

@Zigmund:

Native multicast events/delegates are useful and necessary. Currently when you implement your own technique to assign several event-handlers to one event, you can do this only by ensuring that the last handler assigned to the OnEvent-property calls the next handler.

If however there is code that assigns a handler that is not aware that it has to call the old handler, your system is broken. And this can lead to ugly bugs.

So it is sensible and necessary to have multicast events/delegates built-in, which will handle the event handler-chain transparently (nothing can go wrong accidentally).
August 3rd, 2008 at 6:37 am
58
Maël Hörz Says:

George Says:

AL_one Says:

""And what about assignment operation that returns the value."

No, thanks. Use C++ for that."

Agreed. That is one of the most abused feature of C/C++. I can’t count the number of times I saw really dense and ugly code written that way.

And the example would only work with a weak type system. "Obj := FindNext" would return Obj, i.e. a pointer and not a Boolean. In C a pointer/integer 0 is true, but in Pascal it is a type error (which is good).
August 3rd, 2008 at 6:43 am
59
Maël Hörz Says:

"In C a pointer/integer 0 is true, but in Pascal it is a type error (which is good)."
should be
"In C a pointer/integer different from 0 is true, but in Pascal it is a type error (which is good)."
August 3rd, 2008 at 6:45 am
60
Sip from the Firehose : Delphi 2009 and C++Builder 2009 Live Webinars with David I starting tomorrow, August 13 Says:

[...] New Language Construct for Exit http://blogs.codegear.com/nickhodges/2008/07/22/39079/ [...]
August 12th, 2008 at 10:12 am
61
Paweł Głowacki : Delphi 2009 Online Resources Says:

[...] Nick Hodges blog post: New Language Construct for Exit [...]
November 3rd, 2008 at 12:04 pm

Blogroll

CodeGear

CodeGear Bloggers

Community

Meta

New Language Construct for Exit

61 Responses to “New Language Construct for Exit”