Huh. In python I would probably have the Details constructor take an iterable of enum/constant tokens, e.g. d = Details([Details.INCLUDE_FOO, Details.INCLUDE_DERG]) … is this a terrible idea and/or does it have a sane corrolary in c#?

Does system B use NULL referees to indicate no ref assigned? If so then the suggestions already posted don't work with the database as designed

Wouldn't needing to replace references to the original object be a problem here?

Why would anyone ever want a non-constructor function that looks like a constructor?

The issues can go farther than just compilation, too; I have a muscian friend who can't use the available 64-bit FL Studio because they require many VSTi's that are only 32 bit; other dynamic-link based plugin architectures are simillarly affected.

os.path.join does basically the same thing for python, too

It also depends on the language. In C# or Python you can always go back and make the field a property if you need extra behavior; in Java not so much; the future-change risk of exposed fields is much higher in java.

A typical "leave your email address and a message and we'll get back to you" form is also stateless. When you submit the form the server dosen't care where you got it from, and it just copies the data into some customer service todo list and forgets about it.

For history, I can tell you that (a) python 1.5.2 final was released in 1999 and (b) python 1.5.2 compatability was a big issue for a long time because 1.5.2 was used in a bunch of distro-internal stuff in Redhat for a long time. At least I saw a lot of second hand mentions of the latter a while back. .... For Perl, I have heard people compare it to line noise and call it a write only language, but I know it gets used a ton and I haven't gone there so hard to say. I do remember thinking it was like INFORM (interactive-fiction lang) which I also felt was line noise, at first glance >.>. (#TADS)

I would call the date pickers and sliders "widgets", personally. Widgets are components themelves but a rather small subset thereof. I generally agree with MainMa here, thoug components are modules and submodules and such.

You could also make users using the new functionality use a new function to register the callback, and record then the way it needs to be called. Probably makes more sense for objects that already have a pool of callbacks though.

I would really suggest generalizing your coordinate math into some function bx,by = move(ax,ay,dx,dy) which does bounds checking and so for you. In your language might require defining a basic point class to return the data sanely though.

NP, i'm not all up with html post 4 but it sounded odd. Nice explination, too.

Erm, did you mean html's "onload"?

Python supports operator overloading too. def add(a,b): return a+b is doable. It's converted to a.__add__(b) automatically. ... So yeah, duck typing seems to require some kind of advanced user defined types. Though data members also work, so duck structs would also be possible, similar to this: def addstuff(a,b,t): t.stuff = a.stuff + b.stuff

The only thing i can think of that would require this is parsing sys.argv. Pass that in from main if you have to. Otherwise don't waste your time and brainpower preventing people from calling your module's undocumented/private functions. It's their problem if that kind of thing dosen't work right.