January 2007

Constructor Keyword?

In addition to my Java wish post two weeks ago, here's another idea for an extension of the current Java syntax. Beginners often have difficulties in finding the constructors of a class. Both you and I know that a constructor has no return type and uses the name of the class, but why not make this special code easier to find?

public class Example {
  public constructor Example() { ... }
}

This new constructor keyword could either be a new modifier that would be allowed only on "methods" without return type and with the same name as the class. Or it could be a special return type (like void) allowed only on methods with the same name as the class. The latter solution would have a second benefit: You cannot accidentally add the void return type to a constructor any more (which makes the intended constructor a plain method) - an error that is hard to track down especially by beginners.

Of course this could also be realized using annotations (e.g. "@Constructor"), but IMHO the coding of a constructor should be part of the syntax and not of the meta data.

Hey, maybe it's time to go to the Kitchen Sink and toy around with the Java syntax? :-)

iCab 3.0.3 Beta 438 - Growl

Today's iCab beta version 438 adds support for Growl to notify the user about finished downloads and some other events (note that this feature is supported by the Universal Binary version only). The other items mentioned in Alexander's release history concern better support for CSS3 and some bugfixes:

• iCab supports the CSS 3 properties border-left-colors, border-right-colors, border-top-colors and border-bottom-colors. Using these properties a list of colors can be defined. The browser uses the first color for the outer pixelline of the border, the second color for the next pixel line of the border etc. iCab also supports the "Mozilla" prefix "-moz-" for these properties, so that iCab can display the colors correctly on web pages, which do only use the "-moz-" prefix assuming that currently only Mozilla compatible browsers do support these properties. Unlike Firefox iCab does also support the border-style propertie in combination with these colors. Firefox always assumes "border-style: solid" if multiple colors are defined for the border.
• iCab supports the CSS 3 border styles "dot-dash" and "dot-dot-dash".
• iCab now supports the CSS 3 color definition function hsl() which can be now also used as alternative to the function rgb():
  hsl(hue[number], saturation[%], lightness[%])
• Fixed a crash when JavaScript events were delivered to HTML or BODY elements which were positioned absolutely.
• Alt-Clicks on non-link areas were not reported as event to JavaScript code.
• The GetHeader() method of XMLHTTPRequest objects didn't work.
• Fixed another crash when iCab renders certain invalid HTML code.
• Plugin data which was removed by JavaScript was still active.
• The modified workaround for invalid tables from beta 434 is now modified again to fix a problem with some other faulty web pages.
• Workaround implemented for web web pages where all end tags are missing.
• The workaround for printing image with alpha channel in the UB version is now also implemented in the PowerPC version, because new MacOSX releases don't print these images anymore, otherwise.
• If JavaScript code did pass HTML code instead of a tag name to the "CreateNode" method, iCab did accept this and created a single element with the HTML code as tag name. Now iCab rejects this and reports an error.
• multiple values for the CSS Properties "border-*-width" were not reported as error.
• If iCab was configured to ignore color definitions of web pages, iCab didn't ignore the color of the FONT tags for underlines when the page was rendered in "Quirks" mode.
• When pasting text into the search or URL field special characters (like the German umlaut charcaters) got lost.

Explicit Package Visibility?

Happy New Year to all readers of this blog! With 2007 being two and a half days old already, it's about time to express one's wishes for the months to come. So here's my wish for upcoming Java (200)7 beta versions: Add the possibility to explicitely declare package visibiliy. Why?

I'm teaching Java (and related technologies/frameworks) to many different people, beginners as well as Java programmers with years of experience. There's one misunderstanding I encounter regularly: The meaning of the implicit access modifier for default (package) visibility. Consider the following class:

public class Example {
  int value;
  int getValue() { return this.value; }
}

Here, both the variable value and the method getValue() have package visibility since no access modifier is declared explicitely. Currently this is the only way to use the package access level. This often is a problem since many people expect Java to choose the "best" visibility as default, i.e. private for variables. Some even expect methods to be public by default. (You don't think that default public methods are a reasonable assumption? Well, think of interfaces, where all methods are implicitely public and the public access modifier is completely redundant... This absolutely makes sense - but does not make Java easier to use.)

Changing the "default" (implicit) visibility from package to private for variables and from package to public for methods isn't an option since it would break compatibility of existing source code. But there's an elegant solution IMHO that requires only a slight extension of the Java syntax and does not need a new keyword as we can reuse one already existing:

package de.snailshell.wishes;
public class Example {
  private int value;
  package int getValue() { return this.value; }
}

IMHO this source code is easier to understand for beginners and even offers better readability for experienced Java programmers. The access modifier could still be omitted and would still default to package visibility, i.e. source code compatibility remains preserved. Later on, omitting the access modifier could be deprecated for class members (leading to a compiler warning).

Any thoughts on this proposal? Let me know!

[Update] I'm not sure if readability is maintained if the class itself is package visible:

package de.snailshell.wishes;
import ...;
package class Example { ... }

On the other hand, this notation makes it clear that the class is visible in its package only. Because two different lines can start with the same token now, the compiler's parser needs a lookahead of two tokens. I don't know if this would be a problem with the current compiler (maybe it uses a two tokens lookahead already).