Author Archives: Tenoch

Structs, or value classes, have been a problem since I decided I wanted them. Their only raison d’être has been performance, as functionally they can be entirely replaced by objects. And additionally, the value type semantics is inherent to some … Continue reading →
Continue reading →

Arrays in sool, like in many modern languages, should be a little bit smarter than C arrays. C arrays are just a chunk of contiguous memory, with a pointer to the first element. All the rest is pointer arithmetics. The … Continue reading →
Continue reading →

In the previous episode we talked about callbacks, and more generally, of method delegates, which we decided would be only casting to interfaces with remapping of the method names. A concept often associated with callbacks is the anonymous function. In … Continue reading →
Continue reading →

I’ve been learning quite a lot of Flash recently, and therefore, of ActionScript 3. It’s an interesting language, and I might make a small review of the features I like. Today however, I’ll focus on the library part of Flash, … Continue reading →
Continue reading →

Formal reference: blah I haven’t done much work on sool lately. However, to try and make things more clear, I started writing down a reference of the language, in its current state. It turns out to be a fairly difficult … Continue reading →
Continue reading →

The last few posts introduced some major changes. Let’s see what fun consequences they might have. Global functions By using the factory functions in classes, we can simulate global functions. One in particular stands out: main. I never had a … Continue reading → Continue reading →

A thing came to my mind while writing this about functors. When a class defines a selfless method, object Class selfless no_self() end end it can be called either without an object: Class:no_self() or with one: local instance = Class … Continue reading → Continue reading →

The current state of things is: interfaces are sets of method prototypes. A class is said to comply with an interface if it implements all the interface’s methods. declaring an interface also creates a so called “generic” class. This generic … Continue reading → Continue reading →

I’ve been playing around more seriously with D lately, and learned a few interesting things about it. By using it in an actual (small) program, I was forced to learn it more thoroughly, and many details that had escaped me … Continue reading → Continue reading →

As we know, using nil is a little bit heavy in sool: optional variables must be “casted back” to non optionals using the if as syntax, or the boolean operator or. I was trying to write a simple linked list … Continue reading → Continue reading →

For design testing purposes, I was writing a mockup of some future standard classes, and trying to strain the template and interface system. I got into an interesting situation that suggests that we might need to be able to extend … Continue reading → Continue reading →

One tiny thing bugged me while I was taking a shower this morning, about my big new shiny interface system. Basically, a class implements a few methods. object Foo method bar() end end — call: foo = Foo foo.bar() Then, … Continue reading → Continue reading →

Sitrep: we have interfaces, which simply define method sets. Interfaces are used: as bounds for template parameters (requiring compliance with the interface) as generic types (to which can be casted any compliant class) The major difference being that in templates, … Continue reading → Continue reading →

So, with all we said in the last post, sool now has interfaces, which also defines generic classes that can be used to create generic code, which uses dynamic dispatch to work with every class that implements the interface. An … Continue reading → Continue reading →

So, what would sool look like without the classic inheritance mechanism, but with interfaces, embedded subobjects, dynamic interface type, and template with interface-restricted type parameters? As always, we want light but clear and unambiguous syntax, that exposes in a convenient … Continue reading → Continue reading →

In short, yes. But that might not be a good idea. First, why would we question their utility? they are a pain to code in the compiler, as I’ve been learning recently. Sure, that’s a compiler-writer problem, but still. they … Continue reading → Continue reading →

Inheritance, we know it, is a cornerstone of object-oriented programming, along with dynamic dispatch, abstraction, encapsulation, and subtype polymorphism (your mileage may vary). In particular, the combination of inheritance, dynamic dispatch and subtype polymorphism allow us to flexibly enjoy: code … Continue reading → Continue reading →

I’ve been a lazy person, and haven’t worked on the compiler’s implementation in a while. I’ve been stuck on some big design problems (namely, template class instantiation) and wandered away to easier activities. And, to make things even more stuck, … Continue reading → Continue reading →