Language proposal

  • Thread starter Thread starter cody
  • Start date Start date
C

cody

What if i want to validate the return value of a method but this method has
serveral points where a return statement is.
I know in MSIL there is only one RET opcode in each method and this means
that the method always knows its return value at this point.

int GetValue()
{
try
{
// calculate value, severals return's here
if (a<b)return b;
else if (a==1) return b+1;
else if (b==1) rerturn a-1;
else return 2;
}
finally
{
System.Diagnostics.Debug.Assert(retval!=0); // new keyword retval
}
}

I know I also could use a variable where I store the return value but that
would mean to introduce a new variable.
In Pascal you could access the return value using the function's name.
What do you think?
 
Seems to much ad-hoc for me. Have a look at AspectJ or Eiffel for really
generic solutions to that problem.

Niki
 
Seems to much ad-hoc for me. Have a look at AspectJ or Eiffel for really
generic solutions to that problem.
Click to expand...


I know that there are languages that care much more about validation code as
C# does. Thats exactly why I was proposing it.
 
cody said:
What if i want to validate the return value of a method
but this method has serveral points where a return
statement is.
[...]
I know I also could use a variable where I store the
return value but that would mean to introduce a new
variable.
Click to expand...

One extra variable won't kill you, and will probably help readability.
Trying to follow the execution path of a program can be quite awkward
when there are multiple return statements.

P.
 
What if i want to validate the return value of a method
but this method has serveral points where a return
statement is.
[...]
I know I also could use a variable where I store the
return value but that would mean to introduce a new
variable.
Click to expand...

One extra variable won't kill you, and will probably help readability.
Trying to follow the execution path of a program can be quite awkward
when there are multiple return statements.
Click to expand...

And who ensures that there is only ONE return statement? It can easily be
overlooked, especially you the method is really large and not written by
yourself. If you see an Assert before the return statement you want to make
sure that there is really ONE central point where you have to place your
assert.
 
Paul E Collins said:
One extra variable won't kill you, and will probably help readability.
Trying to follow the execution path of a program can be quite awkward
when there are multiple return statements.
Click to expand...

While that's true, it can also make a fairly simple method *less*
readable to force yourself to only have a single return method. It's
one of those design principle which shouldn't be followed too rigidly,
IMO.
 
cody said:
I know that there are languages that care much more about validation code as
C# does. Thats exactly why I was proposing it.
Click to expand...

Then why do you propose such a minimalistic version, that can solve just one
single case? I personaly do like the aspect-oriented idea, and I would like
to see enhancements in that direction in C#. However, a language
specification shouldn't be a recycle bin for "this-should-be-easier"
situations programers have to face. If something like your proposal shall go
into the language it should:
(a) fit nicely into the existing language concepts (object-orientation,
attributes, metadata, soon generics...) and make most use of these,
(b) it should be generic enough to solve a broad range of problems,
(c) it must be simple enough that most programmers can use it, (although,
looking at attributes, metadata and generics, this isn't half as important
as (b) is)
(d) lots of other requirements I can't think of right now

Your suggestion clearly misses (b), and I don't see much of (a) in it: are
those 'function constraints' in some way reusable? can I apply them like
attributes? are they inherited when a function is overridden? Are they
accessible from metadata? Can I put them on interface functions? Are they
applied only to functions, or could you apply them to types, effectively
putting range constraints on them? ... I hope you see why I call this an 'ad
hoc' solution?

The preconditions/postconditions/invariables solution of Eiffel come a lot
closer, but (in my mind) they couldn't simply be "inserted" into the C#
model, lots of design would be needed to make them really useful.

Niki
 
Seems to much ad-hoc for me. Have a look at AspectJ or Eiffel for
really
code

Then why do you propose such a minimalistic version, that can solve just one
single case? I personaly do like the aspect-oriented idea, and I would like
to see enhancements in that direction in C#. However, a language
specification shouldn't be a recycle bin for "this-should-be-easier"
situations programers have to face. If something like your proposal shall go
into the language it should:
(a) fit nicely into the existing language concepts (object-orientation,
attributes, metadata, soon generics...) and make most use of these,
(b) it should be generic enough to solve a broad range of problems,
(c) it must be simple enough that most programmers can use it, (although,
looking at attributes, metadata and generics, this isn't half as important
as (b) is)
(d) lots of other requirements I can't think of right now

Your suggestion clearly misses (b), and I don't see much of (a) in it: are
those 'function constraints' in some way reusable? can I apply them like
attributes? are they inherited when a function is overridden? Are they
accessible from metadata? Can I put them on interface functions? Are they
applied only to functions, or could you apply them to types, effectively
putting range constraints on them? ... I hope you see why I call this an 'ad
hoc' solution?

The preconditions/postconditions/invariables solution of Eiffel come a lot
closer, but (in my mind) they couldn't simply be "inserted" into the C#
model, lots of design would be needed to make them really useful.

are those 'function constraints' in some way reusable?
Click to expand...
Yes I think so
can I apply them like attributes?
Click to expand...
Why not?
are they inherited when a function is overridden?
Click to expand...
Sure. A baseclass method cannot have less restrictions than the overridden
method has.
Are they accessible from metadata?
Click to expand...
They at least be visible from the outside.
Can I put them on interface functions?
Click to expand...
Why not?
Are they applied only to functions, or could you apply them to types,
Click to expand...
effectively putting range constraints on them?
I cannot think of how this could be done.

But honestly I have not much clue about Eiffel and aspectoriented
programming. If I find time I'll have a closer look on it.
 
cody said:
...
Yes I think so

Why not?

Sure. A baseclass method cannot have less restrictions than the overridden
method has.

They at least be visible from the outside.

Why not?

effectively putting range constraints on them?
I cannot think of how this could be done.
Click to expand...

Ok, I really must have misunderstood your proposal: I thought you only
wanted to introduce a new pseudo-variable "retval" that contains the return
value inside a finally clause. I don't see how I could e.g. apply that to
interface functions (I can't put finally-clauses in them), inherit it (when
the function is overridden) and so on. Maybe you should make your proposal a
little clearer to me...

Niki
 
are those 'function constraints' in some way reusable?
Ok, I really must have misunderstood your proposal: I thought you only
wanted to introduce a new pseudo-variable "retval" that contains the return
value inside a finally clause. I don't see how I could e.g. apply that to
interface functions (I can't put finally-clauses in them), inherit it (when
the function is overridden) and so on. Maybe you should make your proposal a
little clearer to me...
Click to expand...


OK, first I just had the idea that it should be possible to access the
return value of a method. Then you started with eiffel and function
constraints and I got the idea for widening that concept :)
But maybe you are right: It seems that it wouldn't fit into the language.
 
cody said:
...
OK, first I just had the idea that it should be possible to access the
return value of a method. Then you started with eiffel and function
constraints and I got the idea for widening that concept :)
But maybe you are right: It seems that it wouldn't fit into the language.
Click to expand...

I wouldn't even go that far. (I actually do like the concept) But it would
need lots of careful planing to really make it fit. I'm pretty sure the C#
guys spent a lot of time on e.g. generics or attributes, as well.

BTW: You could of couse take the mono C# compiler, and try to implement your
feature!

Niki
 
Back
Top