The Artima Developer Community
Sponsored Link

Weblogs Forum
Implicit versus Explicit Dynamic Typing

95 replies on 7 pages. Most recent reply: Apr 17, 2006 11:09 AM by Isaac Gouy

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 95 replies on 7 pages [ « | 1 ... 4 5 6 7 ]
Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 27, 2005 9:28 AM
Reply to this message Reply
Advertisement
> [from another post]:
> NSWindow isn't an output stream and I can't change the
> inheritance hierarchy, so I subclassed it and implemented
> a couple methods and voila - I can substutute the window
> for the ouput stream.
> */
>
> Perhaps this is inexperience, but it seems to me that
> BECAUSE NSWindow is not an output stream, subclassing it
> from an output stream is asking for trouble.

I didn't subclass it from output stream (ObjectiveC has single inheritance - although you can set up automatic forwarding to produce its functional equivalence). Actually, I didn't subclass it at all, I simply added a couple methods to it using a method category. I looked at the logging stuff that printed to stdout and realized it only called a couple methods from output stream and just implemented those.

> My
> understanding is that you have a window, and that window
> has (compared to is) an output stream.

No, I wanted the window to BE the output stream. So it was.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 27, 2005 1:23 PM
Reply to this message Reply
I appologize if I misunderstood how you set up the NSWindow.

However, if I'm understanding (and you're not being sarcastic, I am on the other side of a pure text medium and I can't take advantage of visual or voice cues, after all), you're new window thinks it's also stdout. And, if I'm understanding that's "window" as in "square thing, comes with a menu bar" and not "widget" as window once meant.

In that case, I would ask "what if you want to pipe stderr to that window as well?" Or "what if you run two instances of the program and you hope to pipe both stdouts to the window but in different text boxes?"

OK, it's your window, and you may absolutely NEVER want to do that. Fine. However I will be the first to tell you that you may be getting that rigidity from the type system when you don't want to. This is what I meant by "typing does not solve every problem." When typing does solve a problem use it, but don't use it if it's an unnatural fit.

Don't reach for multiple inheritence when containment does the job.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Oops, took a second look at the post Posted: Sep 27, 2005 4:32 PM
Reply to this message Reply
/* I didn't subclass it from output stream. ... Actually, I didn't subclass it at all, I simply added a couple methods to it using a method category.
*/

After re-reading this I understood that you were able to do a no-no in the C++ world because you're not in the C++ world. I think I get the point. I'm not sure I agree with it, but I think I get it.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Implicit versus Explicit Dynamic Typing Posted: Apr 17, 2006 6:17 AM
Reply to this message Reply
> Button b = new Button();
> b.addActionListener(new ActionListener() {
> public void actionPerformed(Component target) {
> System.out.println("Button was clicked"); }});
>
> is better than
>
> b := Button new.
> b onClickDo: [:btn | Transcript show: 'Button was
> clicked'].
>
> One of these is hopelessly cluttered with worthless
> boilerplate and one is clear as day.
>
> Verbosity limits your productivity.

In a programming language with type inference and a static type system, it could be written like this:


let b = new Button;
b.onClick({System.out.print("button was clicked")});


which means that less typing has nothing to do with dynamic typing.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Implicit versus Explicit Dynamic Typing Posted: Apr 17, 2006 6:21 AM
Reply to this message Reply
> If you read the documentation for Cocoa on Mac OS X you'll
> come across a concept called 'delegates'. A delegate is
> any object, If the object implements certain methods, then
> the object using the delegate will give the delegate a
> chance to handle an event or action before the default
> action occurs. This is tremendously powerful but only
> makes sense because objectiveC is a dynamically typed
> language.

If the concept of delegate in Cocoa is anything like C#'s events or D's delegates, then a static type system has no problem to deal with delegation. In fact, static typing is better in this case because it enforces an interface agreement between the caller and the callee.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Implicit versus Explicit Dynamic Typing Posted: Apr 17, 2006 11:09 AM
Reply to this message Reply
Achilleas Margaritis wrote
> In a programming language with type inference and a static
> type system, it could be written like this:
>
> let b = new Button;
> b.onClick({System.out.print("button was clicked")});
>
> which means that less typing has nothing to do with
> dynamic typing.

In a programming language with anonymous functions (and a succinct representation for void->void anonymous functions), and type inference, and a static type system,...

The verbosity in this example has little to do with static/dynamic and everything to do with the lack of a succint representation for void->void anonymous functions in Java.

Flat View: This topic has 95 replies on 7 pages [ « | 4  5  6  7 ]
Topic: Bridging Static and Dynamic Typing Previous Topic   Next Topic Topic: Where Did All the Beautiful Code Go?

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use