apple-knowing baskets frankly sound like a hack
need to track that [peeling] separately too?
carry my fruits in a tray instead, does the tray now have to copy all the special-casing that the basket is doing?

I assume the work grows too quickly here, yes.

I don't dare to propose a Basket<mainClass, subclass1, subclass2, ...> with compile-time code generation, even when that's probably possible. Maybe this is truly the land for dynamic typing without any static checks at all? But even those raise errors on unsupported methods...

How does Smalltalk handle [...] still return some sort of default or special value (think null or undefined or similar) for that case?

Most of this is answered by "I erred and Smalltalk doesn't allow it by default." The Smalltalk nil object responds to all messages that the class would normally respond to, and returns the nil object. This looks OK because everything is an object in Smalltalk.

For languages where it must be done explicitly, it just becomes a matter of if/where/how you want to "hide" the check.

Wise interpretation. The three proposed suggestions happen give the three possible answers: The check can go in the element class, in the client code, or in the container class. I didn't see this!

I do agree that the situation you are describing [ie. abstracting out the pattern of "if (supported) dothis() else /* do nothing */"] is not uncommon, and it would probably be useful for commonly used languages to support that case better.

Nnnnn, thanks.

create a boolean attribute for Fruit named isCoreable and then give the subclasses of fruit that are coreable the core() function. Then, you can check each fruit, check if its attribute isCoreable is true, then call the method core().

Yep, this looks like a variant of the fat interface. The Fruit class gets some Apple-specific knowledge.

If you define isCoreable in Fruit, and core() only in the subclasses, then you still have to cast in the client code.

subclasses of Fruit that are coreable implement an interface that lets them be cored. I'm not sure how many languages use interfaces, but Java does, and Python can use abstract classes instead to solve the problem.

In some cases you can also simplify the manual checking by, for example, requiring fruits to implement an ICoreable interface if it supports coring.  So you just have to check for ICoreable and not more explicitly for specific fruit types.

This is excellent when we don't like to put everything right in base class. The example becomes Banana : Fruit; Orange : Fruit; Apple : Fruit, Coreable.

Defining the Coreable interface is probably wise even if we do it solely for explicit dynamic casting later. Coring seems to be a central concern in our domain, otherwise we wouldn't worry as much about this particular design problem. We can well abstract that into an interface and dynamic-cast to that.

---

Bonus: Found a webpage with the exact section from Riel's book! I bought the hardcover second-hand last year, it was splendid bedtime reading. At least if you believe that OO is often good.

-- Simon

Yes, I like RAII helpers in similar situations. I wrapped target bitmaps or blenders in them, these are Allegro thread-local.

Lix is entirely single-threaded. There is theoretical potential to parallelize: D has all mutable variables thread-local by default, Allegro 5 drawing routines have a global drawing target per thread. But multithreading is daunting and my early dabblings in 2015 to parallelize crashed.

In my application, the drawing context switches so rarely that I'd rather not clutter the GUI elements' interface. But enlarging that interface is a good solution in general.

---

Fruit basket problem

(Source: Object-Oriented Design Heuristics, by Arthur J. Riel)

You have a class Fruit, with subclasses Apple, Banana, Orange. In particular, Apples know how to core themselves. And there is a container class Basket, this collects Fruit and allows you to insert and iterate over the fruit. We have lots of different fruits in the basket. How do we iterate over the fruits, telling the Apples to core themselves, ignoring other types of fruit?

The Smalltalk solution is that you tell every fruit to core itself. Calling core on a Banana would be legal even if Banana doesn't understand this, and the banana would do nothing. (Wrong, see 2 posts further down.) The problem becomes much harder in D, C++, or Java; here, it's illegal to call core on Fruit. I like strict static analysis and want the compiler to yell at me.

Proposed solutions:

Fat interface: Make an empty method core in Fruit. Override this only in Apple with the meaningful behavior. Call core on every fruit in the Basket. Downside: Fruit gets special knowledge of Apple behavior. But maybe this is the least intrusive solution.

Explicit analysis: dynamic_cast<Apple*> every Fruit*. This returns null if we have a banana or orange. Call core on what casts successfully to Apple. Downsides: The fruit basket problem is far too common. Explicit case analysis everywhere is exactly what OOP tries to avoid. Instead of littering the entire codebase with special-casings, we should centralize all this special-casing in classes Fruit and Apple. We'd get OOP's verbosity without reaping its benefits.

Apple-knowing Basket: Consider Fruit and Apple correctly designed, but Basket ill-suited for our purpose. By definition, the Basket returns Fruit references, and calling core on Fruit is not allowed. Instead, the Basket should privately maintain a list of Fruit references, and, separately, a list of Apple references that point to the same objects as the Fruit list points to. Downsides: What is the Basket's interface to add elements? Will it dynamic-cast, or should Basket's caller make sure he calls addFruit and addApple correctly? What happens if Basket's caller gets their Fruit from a Fruit source that doesn't support this pattern?

-- Simon

I haven't got fresh ideas. Both the 0.6 or 0.7.1 brick placement bring design problems.

I'll probably introduce 0.7.1 bricks, with brick doubling on blocker turning  builder. It sounds weird at first, why should you get bonus terrain from the blocker, but the doubling is surprisingly nonintrusive and feels appropriate. The blocked bridge is nicely traversable.

-- Simon

I've got the rough work done for the remaining tiles: The bonsai tree, and the red bridges.

I'm not happy with the bonsai tree's stem color, it should match the slightly darker roots and branches. But at least the shapes seem good. That's most important for physics.

But that's all tiles remade for now! Planned course of action:

• Redesign the bridges. Done, see images in this post.
• I migrate all Oriental levels in the main Lix repo: Lemforum community pack, NepsterLix, Rubix's levels, multiplayer levels.
• I merge Raymanni's 3 tilesets.
• I merge some physics bug fixes from the 2016 backburner, release experimental Lix version.
• For each pack maintainer (Proxima, Nepster, Rubix), I'll prepare a list of affected levels with Oriental tiles. Pack maintainers check if levels still look OK, are solvable, and prepare a new proof in experimental if needed.
• Everybody shall complain about physics bugs, tile oddities, etc. in experimental. I love bugs! Tell me the bugs! What is not 100 % perfect? Tell me!
• Release as stable.

Looks a lot better!

Thanks!

I always feel like my energy is best spent on code. Tilesetting is more exhausting and daunting for me. But this set has been nagging me for years. I'm happy that I tackled it and that geoo even contributed.

-- Simon

I solved Nice Catch on stream, then raced geoo in Cavelems and Classic.

Vod of my play, with geoo's and my voice
Vod of geoo's play

Kieran and Raymanni stayed in chat the entire time, thanks!

---

geoo won the Cavelem race by 2 minutes, really close. I won the Classic race because geoo didn't want to backroute Richard's Cliff.

The races have been good fun, looking forward to have more!

Ideally, I'd manage to include geoo's broadcast into my own stream, in a corner. I've looked into local RTMP servers, and while I can test-stream to a server running on my own machine, I haven't managed to watch from it yesterday.

Rage sources, sorted by severity, 1 is severest:

• L2 has abysmal assignment code.
• L2 has no framestepping, but I'm used to framestepping.
• Tiring after 3 hours of Jazz runs, then 6 hours of L2 racing.
• L2 offsets assigned builders and blockers towards the right.
• Nicely rarely: Unnecessary demand for execution in Kieran's designs. Out of the 25 levels that I played on stream, I suggested at most two easenings of execution, in Spiral Staircase and Bass the Baton. Well done, Kieran, in keeping this number low, I know you kept an eye on this!

-- Simon

I recolored the Asian gate, it looks neat in levels now. Used sparingly, it's a nice colorful stamp in levels. geoo drew great bamboo leaves.



-- Simon

Moved Kieran's excellent instructions how to install DOSBox and play L2 to the Help board.

-- Simon

QFK v6 Egyptian by geoo and Simon -- this stream shows both geoo's and my gameplay. This comes close to ccexplore's with for watching a race live. Will expire in 14 days.

Thanks for Kieran for joining twitch chat!

In case you had preferred not to make a twitch account: An alternative for chatting during the livestream would have been IRC (irc.quakenet.org #lix and #neolemmix, webchat). We sit there often, even when not streaming.

During streams, twitch is better anyway. It's one chatroom for all viewers, and twitch saves the chat along with the vod for 14 days.

-- Simon