n2liquid's sandbox

Archive for the ‘Idea Snippet’ Category

Today I suddenly noticed a way to fix a weakness I’d long known in Chii’s users() access specifier. users() has the pitfall that changing one interface would needlessly force all clients of the class to recompile. So I got an idea to address this issue, and also remove the need for C++’s PImpl / Cheshire Cat idiom in Chii, which I believe is just boilerplate and could be handled by the language.

The idea consists basically in making the compiler break a class header into many smaller interface files (“interface shards”) which client code will import instead of the fat one. If the fat class file is changed, the compiler will regenerate the shards, but will only update those that are needed. The impact on clients depends on the changes made.

If the change was:

  • the public structure of the class (i.e. public variables), then all clients must be recompiled;
  • the private structure of the class, and the size of the class (in bytes) or the alignment requirements change, all clients must be recompiled;
  • the method signature in one of the shards, only the clients of that shard must be recompiled;
  • the addition or removal of a method from one of the shards, only the clients of that shard must be recompiled, but some or all clients may need to be relinked (see the reason why below);
  • the private structure of the class, but the size of the class (in bytes) and the alignment requirements don’t change, no clients must be recompiled (this is where PImpl gets replaced by a language feature; in fact, this also performs better than PImpl since it doesn’t use dynamic allocation, but is still safe in ways that I’m not aware to be possible in C++).

Changes in the number of methods in an interface is tricky because it messes with virtual table offsets of neighbouring interfaces. To avoid recompiling unrelated clients, I’m considering putting the offset to the beginning of an interface on the vtable in an externally linked constant. During link time, I should be able to just link the objects with another one containing the constant. That’s why some clients might need to be relinked, but not recompiled in case of method additions or removals on the class.

I’m crazy to try to implement those things, but I’m really out of time to do that… Anyways, I hope all of this makes sense and is somewhat exciting to whoever is reading.



I have recently created an account on MyFigureCollection.net, a really nice site in which you can post and manage collections of action figures you own, favorite and comment others’ photos, etc. It is pretty much a small social network for action figure enthusiasts.

Hatsune Miku and Black Gold Saw (MFC.net banner by Danboard_san)

The site contents truly is amazing, and I’ll certainly actively participate in it once I get a fine camera and more figures.

Overall the site is pretty good and the idea is really nice, but the service is not as good as it could be.

The matter of what is good and what is bad is pretty much personal, and there’s likely people out there who love MFC (no, not that MFC), but the site has a long way to go to suit my tastes in plenty.

For example, I think the site design could be greatly improved. Of course I can use Greasemonkey to do that, but people wouldn’t see it if I sent them links to my profile, so that only solves half the problem.

Another thing is that if I wanted to create some crazy relationships between my images (like saying 3 images have the same pose, only each has a different background and the last one is photoshopped to, say, remove the joints) I would have to resort to linking them in the description.

But I want better.

For a moment I thought about making a similar service with the changes I’d like to see, but I noticed it wouldn’t be worth it. Most people would stay in MFC.net, some would use both, and we would have the redundancy and mess that Orkut, Facebook, Google+ et al introduced.

It then striked me that these kinds of things wouldn’t happen if web federations like we had in Google Wave were more common.

Federated webspaces

Google Wave’s intent was to reinvent e-mail. One of the most important characteristcs of how e-mail works is that it is distributed.

Can you imagine how far behind we would be if we had a single e-mail provider? It could be Hotmail, guys!

The ability to set up a new mail server is something we take for granted, and we think we would be in a ridiculous position if we couldn’t.

And what if we had multiple e-mail providers that couldn’t send messages to each other? If your e-mail ended in @hotmail.com and mine ended in @gmail.com, I would have to create a Hotmail account just to send you a message. How freaking awkward would that be? Insane, isn’t it?

Insane it is, but that’s what we do when I’m on Facebook and you’re on Google+ today.

The creators of Wave obviously knew all this, and since they wanted to make “a better e-mail”, their product couldn’t have such a major setback, so they developed the Federation Protocol: a way to allow waves to cross server borders.

Not long ago, if I remember correctly, there was a big fuss around Facebook and its apparent reluctance in permitting users to interact with other services such as Twitter. Facebook has obviously changed its mind now, but they still don’t want to give users the ability to export their own data.

Also recently, Google decided to ban Anonymous from G+, and there’s been a lot of discussion on whether they should allow codenames to be used in their network. Some guys from Anonymous then decided to start work on their own social network, Anonplus (which, by the looks of it, isn’t going too far, but it is a noble initiative), but integration with other services is sure going to be tough.

There are many reasons to make social networks interact with each other, and it’s pretty much common sense that this is an important feature to have because the very idea of social networks is that people should be able to interact, and people are scattered across many different services.

One way of achieving such interactions is by federating a social network service just like we did for e-mail and Google Wave.

There is a social network called DIASPORA* being developed, whose server anyone can run an instance of locally and participate. This is by far the most promising social network project I’ve seen.

What I find, as a developer, particularly cool about federations, is that it allows nearly limitless personalization and improvement of services without breaking things. If MFC.net had a federation protocol, I would be able to friendly extend it instead of starting everything from scratch as if I hated it entirely. MFC.net is cool, I just want some small improvements here in there. No need for a wholly new service. That’s drastic.

Now, as a person, what I find important about federations is freedom.

If a service like G+ decides to ban me because it doesn’t like the ring of “n2liquid”, or because I’m excited about all the mess Anonymous is causing, I can just take my stuff and go to another server; maybe even my own if nobody likes me, and, in this case, I wouldn’t have to start a new social network project like Anonplus from scratch. I would simply pick something pre-made and put on a server, WordPress-style.

I hope somebody makes an easy-to-use framework for this so that everybody can effortlessly build the web of the future. XMPP is cool, but it’s nothing more than a foundation for such a framework. As it stands, I don’t see many people making simple websites like MFC.net using it for building federated networks.

I hope federations become the rule. It’s not just cool; it can become a pillar of internet freedom.

Quick, what was the most important driving motivation behind object-orientation? Yeah, you got that right; it was that of creating a 1:1 relationship between software and the real-world problem-universe it had to deal with (I’m sure you knew this; if not, I’m not sure you’ll be much impressed with the rest of this post).

The big idea was that objects would map to real-world “things” (and classes would map to the concepts behind those things).


At first, it looks like object-orientation in languages like C++ and Java do this mapping really well. For example, you have “Car” classes representing what a car is (concept), and “Car”-type variables representing the different cars in your application (individual instances). That applies for anything: clients, bank accounts, users, blog posts, and so on.

Marvelous, ain’t it?

Kitsu Chiri burying Java engineers

I could go on on how interesting inheritance and subtype polymorphism is, and what expressiveness possibilities they grant to developers, but I don’t have much time, so let’s get straight to the point of this post:

Object-orientation as it is fails miserably to express many simple real-world systems because it is not thorough enough — it’s uneven.

Although we have means to outline concepts and instances, our ability to imbue their relationships in code is very limited. Inheritance isn’t a catch-all solution to describe relationships between objects like classes and objects are to package real-world stuff. Far!

Things can have different uses for different users. That’s why I came up with the users () specifier. With it, you can express in plain source-code that only Game Masters can kick or ban Players, for example. You get language support for that kind of thing.

There is another family of similar relationships that I’d like to see getting language support too, though.

Let’s keep the Game Master vs. Player example. Game masters are game masters no matter how you look at them. The same applies for players. But what about relative concepts? Two players can be friends and share a special API for friendly interactions. It’s like they implement a special interface (“Friend”), but only between themselves; only in-private.

Those relative concepts can currently be expressed in C++ by means of protected and private inheritance, but most people wouldn’t understand it because, at least as far as I know, the original intent of non-public inheritance wasn’t that of supporting this kind of thing.

C++’s protected and private inheritance usage “should not be seen as an IS-A relationship, but rather a HAS-A relationship“. As I see it, private inheritance can be used to build IS-A relationships. Private IS-A relationships, that is:

If I have a Friend reference to a Player called David, David IS-A friend for me. This isn’t composition, guys! I’ll call it a private relationship from here on.

Well, actually this is all a matter of how you see things: one could argue that David HAS-A Friend-type handle that it can let some others access. In fact, this is the correct interpretation of my example in the C++ world. But the point is, C++ has a feature that can be bended to make something useful (as I see it), and I wish I could have such a similar feature that allowed me to build private relationships without bending anything.

Another problem with the use of private inheritance to do this is that friends may not be friends forever (aah, the finity of all human things; that’s so sad).

How can you ensure that, once a friendship is broken in game, that’s reflected in code? Sure, you can write code to release the Friend handle, but that’s artificial: we want software to truly reflect our systems without us having to explicitly check stuff like we do today in Java, C++, and pretty much any other language.

Key here is that those languages widely are imperative, but their object-orientation constructs are declarative, and that’s what makes their expressiveness shine compared to languages like C. I want to extend object-orientation, as the largely useful declarative construct it is to map software to real-world systems, pushing it closer to those noble original intents, by declaratively covering a wider range of real-world relationships in software.

I think I’ve outlined an interesting solution to part of the problem in Public, Protected, Private, and Beyond, but unfortunately I’m quite clueless as to how to do the same with the private relationships I explained above. I’ll get back to this in a future post.

Hoping you’ve enjoyed the read. And always remember: Chiri doesn’t like uneven OOP/OOD and will react accordingly.

I’d like to make a real quick introduction to Chii’s users () access specifier construct.

When defining who has access to which member of a class, the programmer can specify not only the traditional public, protected, or private specifiers, but also a list of classes. As a consequence, some aspects of a class will only be accessible by classes semantically related to them.

To illustrate, picture a class called GPUMemoryManager, and another one called GPUResource. Since GPUResources occupy GPU memory, it needs to ask the memory manager to allocate it.

In classical object-orientation, I can see this scenario solved in one of two ways: either the GPUMemoryManager allocates memory for anyone that asks it (e.g. it has a “public GPUBuffer allocate()” method), or it is embedded into GPUResources. Either way hurts encapsulation, since not everyone should be able to allocate GPU memory, and GPUResource shouldn’t have to deal with the internals of the allocation.

In Chii, the classes would be kept separate, and only GPUResources would be allowed to allocate memory through a well-defined interface:

class GPUAdapter
users (any): // alias: public
    construct() { ... }

users (GPUAdapter): // alias: protected
    void internalWork() { ... }

users (none): // alias: private
    GPUAdapterGuts mInternalData;

users (GPUResource): // something new!
    GPUMemory allocate(...) { ... }

This is similar to C++’s infamous “friend class” construct, but more restricted, in a way that helps encapsulation, while solving most of the problems it was intended to solve (in fact disallowing only the bad use cases of it, in which people would do perverted things with an object’s privates~).

This is gonna be pretty quick again.

The concept of a fourth spatial dimension is not new to me, but a few days ago I imagined how I could fit that in a video-game. Today I figured I could make a pretty easy to implement game consisting of a randomly generated 4D maze. The maze would be rendered as cubes with at least one door, but up to 6 doors, which are all orthogonal to each other.

The 5th and 6th doors, when they exist, would be accessible by some sort of magical gameplay I haven’t decided yet. The player is gonna be given a 4D “hypermap” which he can turn and twist around in order to figure out where to go. The hypermap will be the most exciting part, since everything else will just look 3D.

I’m just noting this down so I don’t forget later. If you’re interested in working in something like this, please drop me a line.

Recently I’ve been playing Ragnarok Online and figured I could exploit a property of pseudo-random number generators (PRNG) to synchronize some real-time information in online games without relying on “just-in-time” network packets (that is, without having to broadcast the information everytime, the moment it changes).

The idea is straightforward: send out PRNG seeds to network peers and let them use that to figure when, what or how special events (like when an attack was a critical blow or how much damage one caused) happen. This results in instant feedback for the player (making latency look lower) while reducing network traffic, which may effectively reduce latency for packets that really need to be delivered in real-time (such as non-deterministic state changes).

If cleverly implemented, the trick could be used in very large proportions, such as synchronizing the actions of monsters across many clients while they’re not engaged in battle: the server just sends out idle monster information to the clients, a controlling seed and the iteration counter; as long as they’re not affected by non-deterministic factors (like interacting with a player), the server does not need to send any other synchronization packet whatsoever, and every client has an accurate image of the game world. That’s zero packets and absolute synchronization, an almost utopic scenario!

Of course, you still have to synchronize the generators in some cases, but a lot of different information that would otherwise call for a network packet can be extracted from them.

As mentioned, this doesn’t work for all real-time datum, but it does for a handful, and I’m confident small protocol optimizations can account for massive improvements in some online games like, well… massively multiplayer online games.

I’m not sure any game uses this, but I’d be impressed if none did. If you know of any, I’d be interested in hearing about it.

I’ve always loathed having to prefix my variables with dollar signs in languages like PHP. I guess they decided this so that you’d be free to name your variables the way you wanted without conflicting with language keywords.

I dislike how the code looks like, cluttered with $’s everywhere. I noticed, though, that inverting the game could solve my issues — if we had a language where the keywords were prefixed instead, an aware source editor could remove the prefix from visualization and at the same time style the identifier as a keyword. Easy syntax highlighting and the best of both worlds: no conflicts and no (visible) prefixes. The only problem is that the source would look more cluttered than usual in an unaware editor.

In case you’re wondering why this couldn’t be done with variable name prefixes, that’s because simply removing the prefix would give no visual clue that it’s there, which is bad (if you forget it, you can’t see it’s missing since the variable name would look the same as if you didn’t). Moving the prefix somewhere in which its presence makes some other visual difference works, though, because, in case you forget prefixing it the syntax won’t color up.

Following this same reasoning, I noticed two dollar signs could be used for typenames, in a way that keywords, typenames, and variable names all have separate namespaces, can’t clash with each other and greatly simplify syntax highlighting.

Thus, something like:

$var buzzer = $$buzzer(2); // creates variable ‘buzzer’ and assigns an instance of type ‘buzzer’


var buzzer = buzzer(2); // creates variable ‘buzzer’ and assigns an instance of type ‘buzzer’

Naturally, you can also name your variable ‘var’ without a problem:

$var var; /* becomes: */ var var;

I’ll consider using this on Chii.

Cute bouncing pixels


Twitter (technical)

Error: Please make sure the Twitter account is public.

Get messaged when I post something new!
Just enter your e-mail and hit Follow:

Join 171 other followers

%d bloggers like this: