Object Icon co-expressions: name, succeed, fail and fate

Robert Parlett has released Object Icon 2.4 as an O-O UNICODE implementation of the Icon programming language.

But another Objecticon is also appearing as the trademark of an unrelated dot com.

This is sad, given the much earlier choice of Unicon for extended-Icon.

Was ICON a sorrier name choice than SNOBOL ?

IconOO appears to be available: "Icon-Oh-Oh" ?

IconCR (as in Icon co-routines) also appears to be a trademark (Eye-Conquer.)

What remains is the sobering reality that UNICODE came to so many advanced languages so late.  How and why and where did "innovation" fail to occur in this area?

Then there is Curl from www.curl.com which was UNICODE from the start and never got a foothold.  And failed to protect its MIT trademark ...

Is it possible for "Object Icon" to be protected?

ObjectIcon HttpServer without minify-me

Here are a few notes on code in ObjectIcon 2.4 httpclient.icn and related files.

class HttpClient(NetClient)

# and in netclient.icn

class NetClient(Connectable, SetFields)

# in connectable.icn
package util

class Connectable()

My first thought is that Connectable - with no parents, no imports, would have served so much better as a Trait in a traits package. Here is the top of setfields.icn

package util

import lang

With that import, would SettableFields be a Trait?  Here is the head of that class

class SetFields()
   #
   # Generate the {Field}s for the given list.  Note that the list is
   # emptied by this function.
   #
   public static generate_fields(l)

Field is a class found in the same file.  But the problem lies in the last method of generate_fields with

suspend Field(attr, val)

Now we do not have a trait.  And then there is non-documenting code  (really not Icon-esque in 2010 ) which should at least have been

public static generate_fields( lst )

because this is not minify-me JavaScript at Google or Yahoo or qtask.com or...

This is not some stylistic quibble: in open-source code this can be decisive.  Style guidelines count as a matter of quality code.  Quality does matter.

ObjectIcon issues with packages

ObjectIcon 2.4 has folders in its ./lib for /gui and /main

What makes this arrangement an issue for me is the need to intuit what falls in 'main'.  Consider the package net.

In the /main folder we find cgi.icn  but only a 'grep' with Icon would tell you that this was declared package cgi and not package net   A comparable problem faces all OOP with classes when the code base is file-based (Smalltalk is the most notable exception in its use of a bytecode image.)

This is my result:

./address.icn:package mail
./base64handler.icn:package mail
./cgi.icn:package cgi
./codec.icn:package lang
./compoundedit.icn:package undo
./connectable.icn:package util
./constructor.icn:package lang
./contentdisposition.icn:package mail
./contenttype.icn:package mail
./encodinghandler.icn:package mail
./errno.icn:package posix
./evmonconsts.icn:package lang
./evmon.icn:package lang
./exception.icn:package exception
./files.icn:package io
./flag.icn:package util
./format.icn:package util
./graphics.icn:package graphics
./group.icn:package mail
./httpclient.icn:package http
./httprequest.icn:package http
./httpresponse.icn:package http
./ioconsts.icn:package io
./keyboard.icn:package io
./langprocs.icn:package lang
./listener.icn:package util
./location.icn:package lang
./mailbox.icn:package mail
./math.icn:package util
./md5.icn:package util
./messagehandler.icn:package mail
./message.icn:package mail
./mimeheaders.icn:package util
./misc.icn:package util
./msg.icn:package ipc
./multiparthandler.icn:package mail
./multipart.icn:package mail
./mysqlfield.icn:package mysql
./mysql.icn:package mysql
./mysqlres.icn:package mysql
./netclient.icn:package net
./noophandler.icn:package mail
./notes.icn:package notes
./popclient.icn:package mail
./posixconsts.icn:package posix
./process.icn:package util
./proc.icn:package lang
./prog.icn:package lang
./quotedprintablehandler.icn:package mail
./rfc1522.icn:package mail
./rfc822parser.icn:package mail
./sem.icn:package ipc
./setfields.icn:package util
./sets.icn:package datastruct
./shm.icn:package ipc
./smtpclient.icn:package mail
./streams.icn:package io
./system.icn:package posix
./tables.icn:package datastruct
./texthandler.icn:package mail
./text.icn:package lang
./time.icn:package util
./timezone.icn:package util
./typehandler.icn:package mail
./ucodeconsts.icn:package lang
./undoableedit.icn:package undo
./undomanager.icn:package undo
./unicodedata.icn:package unicode
./url.icn:package net

A little daunting when not ordered ... but also worrisome was how seldom the reserved word package occurred in those same source files.

[ TODO add the Icon code for sorted pkg list output ]

Micro-ISV do not exist for MSNBC

micro-ISV search fails at http://www.msnbc.msn.com/?id=11881780&q=micro-ISV&search=&p=1&st=1&sm=user 


As do μISV mISV and Micro ISV also fail

Micro-ISV, ObjectIcon and the importance of UnitTest

ObjectIcon without a UnitTest framework is just not suitable for a MicroISV (mISV or μISV).

I can find no trace at the moment of Art Eschenlauer's UUnit for the UNICON branch of ICON.

I would suggest that the micro-dev would be better to add quality text facilities (comparative search, PEG) and minimal logic programming (with Backtalk constraints ? ) to a Pharo Smalltalk image and thereby get a UnitTest framework, a refactoring browser and versioning and more.

Reduced lines of code and increased productivity, RAD, extensive libraries, ease of maintenance and documentation - these are all Smalltalk strong points.

PS
I did find this link regarding using JUnit style with Unicon.

Objecticon and the Seven Languages

If a second edition of Seven Languages in Seven Weeks came out as the e-book Ten Languages in Ten Weeks, I would hope to see one of either Curl, Rebol or ObjectIcon in that book.  Or Converge.  But not likely Ioke.  By that time Curl may chiefly be seen at the Japanese site of Sumisho, but ... maybe Seph will have matured ... and Simple Smalltalk.

Ioke? The performance. Try it.  Tuning will not make a rock into a Steinweg.

And yet SNOBOL begat SPITBOL and SnoCone - so it would be nice to turn out to have been wrong in the spirit of science and evolution.

Xunit Framework for ObjectIcon?

I added a note at code.google.com/p/ObjectIcon as I see this lack to be a real issue.

To me it is as much an issue as if it were not possible to place comments in source files.