generateui

Those icons are absolutely horrible. They are images, distracting the viewer by the amount of details. Icons should convey only the bare minimum of shape. The metaphor of the meaning should be captured, not the incredilous picture of a remotely possible parrallell.

A typographer, talking about screen density, and clarity on his blog using a serif font. Oh, the irony.

Your consuming code is tied to Foo. In dart, the consuming code only needs tying up to the interface.

> You always need a class

Nope. That's the whole point which I am trying to communicate: you do not need a reference to a class to get the instance of the interface from, as you confirm later on:

> As to the calling code needing to know about that one concrete implementation:

My personal feeling of liberation comes from the fact that the code is simpler and more clear. The non-coupling is nice, but can be achieved with dependency injection too: the point is the transfer of characters into a mental model which is more efficient with the named constructors/factory constructors.

> A factory method is a classmethod, not an instancemethod.

This completely depends on your implementation. It's possible to implement it as instance method, or static method.

> Uh no it does not, it just needs a class.

Whether it be a static factory method or an instance method, fact is you need a reference to an implementation (class). In dart, you can do

  List someListInstance = new List();

where List is an interface. There is none class needed in your consuming code, none. In C# or Java, this is impossible: You need _some_ class (whether it be a static method on it, or an instance method) to get a new instance of the interface.

Named constructors felt very liberating when working with Dart.

  new List.from([instance1, instance1]);

delivers a lot of clarity, while offering the promised decoupling by the GoF:

> Define an interface for creating an object, but let the classes which implement the interface decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses.

There does not need to be any knowledge of _any_ class. A factory method _still_ needs a class instance, you don't need them with factory constructors.

A classical, say Java or C# way will still need coupling to such a class. In dart, there is real decoupling going on.

I am very curious to the business model Diaspora will pursue. any details about that already?

After it became apparent by parlement representitives they probably had to pay "chatheffing" - chattax, this law was reality quite fast.

It's pretty hopefull the law passed senate unanimously.

If the producer would share the design of the iron with the world, the risk would be reduced significantly. The leftover parts could be identified by crowdsourced databases as nonimportant, or as risky to leave out.

Can you define "support"?

Well said. Also, we engineers let lawyers eat our lunch. Law is there for a reason, but we should dominate law, and not let law dominate us.

This is potentially very destructive to Silicon Valley.

That's where inifinite scroll is a good idea. Infinite scroll is usually correctly applied to datasets where it is unknown how many items the dataset consists of. E.g. google images, tweets, et cetera.

We already have what you want, it's called a scrollbar ;).

And software engineering is quite dissimilar, if not completely different to computer science. Creating API's, building user interfaces, testing, has little to do with computer science, or information theory, or mathematics. Yes, it has some overlap, but not nearly as much as academics like to think.

Take an example as implementing a 3D renderer. A computer scientist might argue that underlaying 3D calculations should be correct. A software engineer might optimize for speed, and simply allow incorrect/imprecise calculations, as long as the rendered result does not look very different.