Other than namespace pollution, what's really wrong with PHP? I see that brought up a lot but not much else. Nearly every language has function name inconsistencies and you have to make an effort to remember module and function names for those too.
the object model looks like a hack, implicit casts between strings and integers are going to haunt you, insecure-by-default settings (mostly solved, luckily) - basically it was designed like a language suitable for prototyping, then used as the real thing.
Anyways, the point is moot because PHP is a language to get things done in, not a high-level proto-language or especially OOP style. And it works. I use it as a general-purpose scripting language without OO and save a LOT of time.
right, php is there to get the job done - if this job can be expressed in less than 2000 LOC and consists of lots of html and not so much logic, I even think, php is worth it, at least for prototyping.
As for incrementing, I don't see the need for iterators. You'd just make an array (or 'collection', if you'd rather) of objects and foreach through them. What's that? You abstracted the collection behind a massive API so you can't do that? Get rid of your fucking APIs.
so how would you "foreach through" a tree, using several strategies (depth first, breadth first, ..)? would you copy it to an array first? would you invent a new API?
how about: build an iterator object for each strategy once, when you need it, apply this iterator to your tree, then move through the tree - no "foreach", still native handling, and easily reusable code.
Every time I see:
class Foo { int a; int getA(); void setA( int value ); }
I just go CRAZY. It might be useful for some things like automatically cascading changes onto other classes, but just putting it in for the sake of it exemplifies everything evil about OOP. Then again, C++ isn't particularly well designed. It wouldn't be bad for there to be built-in access controls to prevent values from being modified from outside the class.. oh wait, we DO have that, it's called private.
in this example, a _would_ be private, and getA/setA would be public.
the thing is, you want to be able to change the class, so that a is something entirely different or that some invariant can be fulfilled (eg. some other, dependant variable must be updated) - using those accessors is thus good style and an example of encapsulation: getA/setA would be able to transform your old argument to the new a (whatever it is), transparently, without you changing code that accesses this property of the class in 1000 locations.
some languages provide some syntactic sugar for that, eg. C# and ruby. they want you to use accessors, but they're mapped onto Foo.a and Foo.a= internally, which are proxied through some method. finally it's simple again.
I hear a lot of people talking about Smalltalk but few actually using it to code anything. I hear it has a very nice design to it, 25 years as you say. But is it useful for real world implementation?
probably the biggest draw back of smalltalk (and lisp, forth, and java to some extent, too) is that they're systems - basically every other language provide direct access to the unterlying system, while those language were designed as systems (back then, when there was no such thing as today's elaborate operating systems), that are able to work stand-alone.
for web applications, any of these languages is fine server side, as the client doesn't (need to) know what it's dealing with.
why smalltalk is referred to by everybody and their cat is, that it's the current high ground in OOP design. MVC, Design Pattern, Extreme Programming, etc. all came out of the realm of smalltalk. unfortunately it is not where the money is - those with the money tend to avoid risks and stick with "C-like" languages, as their developers know "C" already.
let's split languages by their syntactic features: those with curly braces, those with pascal-like begin..end statements, and the exotic ones.
for some reason people seem to think that it's easier to stay in the same decoration - which is why c++, php, java, C# are so successful compared to other languages of their days - C (and later c++) was the "gold standard" they wanted to cater to.
the problem is, it makes things _harder_. ever tried to switch between c++ and java several times a day? pretty much the same syntax, but different semantics. I prefer to have an entirely different (yet, _simple_) syntax so the compiler or whatever will scream at me, when I tried to write in the wrong language.
That Seaside system also looks wonderful but I am naturally suspicious of it. I had a similar idea a while back about making one program for the whole site, and having the web pages get handled by the interpreter - this is it. But there have to be a lot of constraints attached?
the feature of seaside lies in the blocks - you only have them in few other languages (ruby, lisp, and python is supposed to get them soon)
Code:
renderContentOn: html
html heading: count.
html anchorWithAction: [self increment] text: '++'.
html space.
html anchorWithAction: [self decrement] text: '--'.
this code produces something like <h1>5</h1><a href="?1">++</a> <a href="?2">--</a>
and if you follow the "++" link, the block
"[self increment]" is executed, which leads to a method that increments "count".
boring example, probably even overkill, but it's that, an example.
now, the system allows for some fancies: how would you store that count value in php - in a session? add it to every link, so that the state is up to date?
session means, if count starts with 0, and you press "++" twice, you get "2".. press "back" in your browser, you'll see "1", press "++" - oops, you get "3" - not intuitive.
having the state in every link would help there, but 1. that can get pretty big (think of the whole state of a shop), 2. you probably don't want to expose all elements of your session, for secrecy or just to make sure things stay consistent.
seaside solves this - the "session" is stored with each of the blocks, which have unique ids that are used in the html.
currently, most web development is page based.. you provide some options, get some values back, do something with those values, then decide what to do, and provide a new page - real ("native") applications don't work that way, and seaside is modelled after such applications.
edit: it's getting pretty off-topic now, don't expect more answers from me here
