Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #1879

Re: functions as objects

Show all headers | View raw

On 7/4/2012 2:28 AM, Dmitry A. Kazakov wrote:
> On Tue, 03 Jul 2012 14:56:49 -0500, BGB wrote:
>
>> On 7/2/2012 10:26 AM, Stefan Ram wrote:
>
>>>     Yes, but this also gives some more type-safety insofar as
>>>     two methods are not confused when they happen to have the
>>>     same or matching signature (as in duck typing) but different
>>>     semantics, because the class defined also needs to implement
>>>     a certain interface, which also yields documentation of the
>>>     semantics.
>>
>> Java makes all this unreasonably awkward though (IMHO).
>>
>> it is much nicer to have faster/easier/lighter-weight alternatives, such
>> as C function pointers, or C++ method pointers.
>
> Null and dangling pointers are especially attractive candidates...
>

this is a side issue, but rarely are they that big of an issue (and 
checking a function pointer for NULL can itself be useful, such as to 
determine whether or not the function or method was given).

point being, they are faster, easier to use, and lighter-weight than the 
use of objects.


meanwhile, if a NULL function pointer is given, and it results in a 
crash into the debugger, and a 'null' object is given resulting in an 
uncaught exception and landing in the debugger, what, really, is the big 
difference?


to add to the topic:
C# has "delegates", which serve a similar role to function pointers in 
this case.


>> or better yet, to have a language which (actually) supports closures.
>
> A closure carries an implicit context allowing accessing it at the callee's
> side. Since the effect of a call is not limited to the arguments declared,
> closures are barely testable and lack contracts to be verified upfront.
> Even most vegetarian downward closures may cause troubles.
>
> The advantage of having an object is that all things the operation would
> touch could be placed in there. It is not always a better choice than a
> downward closure, but frequently it is.
>

the problem though with an object is that often creating them requires 
more code, calling them requires more code, ...


full closures allow many nifty things to be be done more easily (such as 
callbacks which return their values directly into variables, ...).

similarly, internal support of closures may also aide in implementing 
some other useful features, such as "ifdef" and asynchronous 
code-blocks, ...


in the case of Java, there are a few little code-saving features in the 
form of anonymous classes and "lambdas" (JDK7), but given how they work 
internally, they are a bit more limited than what can be done with full 
closures.

meanwhile, a language with closures may have much less need for the 
likes of anonymous classes and similar.


granted, we don't always need full closures, and if the language can 
support (implicit or explicit) non-closure blocks, this can be useful as 
well (may help avoid some run-time overhead in the case where no 
bindings are captured from the parent).


for example (in an unidentified language):
var v:int;
fun{v}			//closure, implicitly has signature "variant()"
fun(x:int){x+v}		//closure, has signature "variant(int)"
fun():int{v}		//closure, signature "int()"

meanwhile:
fun[=v]{v}		//capture v by value, "variant()"
fun[=v]:int{v}		//capture v by value, "int()"
(capture by value does not allow altering the caller's copy)

fun[&v]{v}		//capture v by reference, "variant()"
(say, in this case, the parent's scope may be transient, placing a 
lifetime-limit on the closure)

fun[]{v}		//"error: undeclared variable v"
(block explicitly does not capture bindings, rather than implicitly by 
not referencing them).

fun(x,y){x+y} //non-closure, nothing is captured as nothing is referenced.
fun[](x,y){x+y} //technically equivalent (the "[]" is no-op).
...


>> "type safety" is IMO often more of a "false concern",
>
> Really? If the "true concern" for you is the program length, then it seems
> that you have problems of handling that program. Why do you have them?
> Because of bugs? So, safety still seem to be a concern. Now, how strong
> typing is false safety and pointers [to functions] is true safety?
>

it is not about program length, but rather about productivity.

productivity is often closely linked with code-output volume, where if 
there can be, say, a 2-3x reduction in the number of lines of code 
written to complete a task, then there may easily be a comparable boost 
to overall productivity.

the problem is that many of the "type safety" rules are themselves 
frivolous, like making it an error condition to have an implicit 
up-cast, requiring doing the same things just using considerably more casts.

granted, there are cases which could use a warning, but a warning is not 
the same as an error (a language could have something like "error: too 
many warnings" or similar though).

similarly, having the programmer chase down nit-picky issues (to get 
their code to compile) may likewise hide many larger bugs, which are not 
themselves due to types, but rather things like math or program logic 
(IME: these are far more likely to be the source of problems).

example:
the programmer might care that they are implicitly converting from a 
float to an int or short (or long);
they probably don't need to care that they are implicitly converting to 
a double;
likewise for int->long vs long->int;
it may make sense to complain about implicit conversions long<->double, 
given going either way may lose part of the value range;
...


in other cases, yes, a raw pointer can be destructive, and is maybe not 
necessarily the ideal way to deal with general-purpose object 
references, but this doesn't mean that a language should lack them 
altogether (rather, they can be made into a background feature, much 
like goto and inline ASM and similar).


now, for type-safety and function-pointers:
it should be sufficient to check that they have the correct signature.
a programmer is fairly unlikely to screw this one up by accident.

say, if we get an error like "error: incompatible conversion from ' 
void(int,int)' to 'int(Object,int)'." or similar, this should be good 
enough, and does not require the creation of explicit objects in which 
to hold the function.

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

functions as objects bob <bob@coolfone.comze.com> - 2012-07-02 08:15 -0700
  Re: functions as objects Rui Maciel <rui.maciel@gmail.com> - 2012-07-02 17:42 +0100
  Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-03 14:56 -0500
    Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-04 09:28 +0200
      Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-04 10:08 -0500
        Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-04 18:12 +0200
          Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-04 14:02 -0500
            Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-04 22:20 +0200
              Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-04 19:42 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-05 11:30 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-05 10:33 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-06 10:50 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-06 08:32 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-06 16:45 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-06 10:48 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-07 21:28 +0200
                Re: functions as objects "BartC" <bc@freeuk.com> - 2012-07-08 16:33 +0100
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-08 18:20 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-08 16:27 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-09 09:35 +0200
                Re: functions as objects "BartC" <bc@freeuk.com> - 2012-07-09 09:48 +0100
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-09 11:40 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-09 11:02 -0500
                Re: functions as objects "BartC" <bc@freeuk.com> - 2012-07-08 16:34 +0100
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-08 16:11 -0500
                Re: functions as objects "BartC" <bc@freeuk.com> - 2012-07-08 23:35 +0100

csiph-web