2.07.2011

Access methods vs. operators

As I start - starting from the very small things is always more pleasing than having all the bulk shit in mind. So I'm doing exactly this, coding an array class that really cover all things I'd never need. For me, concepts with iterators and so on aren't that... efficient. Of course, I could still make them templatey and rather OOP-less, pushing performance to a maximum. But I still see the core elements - arrays, sequences and different kinds of lists. I know I can create every special of memory with them as a base, so there's no reason to create such a complex concepts requiring me to remember more function and write a shitload of code just to access a single element. So I'm brainstorming the most nice way to do this. At first I had a lot of methods in mind doing all kinds of different things with different with and range check, different ways of accessing, etc... But in the end I thought: why so complex? Only thing you need is a reference or pointer, this way you can access everything. And you don't need to write so many methods you need to remember then. So my is to keep the access as simple as in C - [] for unsave element access and () for safe access. I kind of fell in love with designing the "best" interface for a class to suit my needs. But since I know I won't really use the "safe access" methods, I don't think I should tinker with them too much. Only problem using the bracket notation is that you can't really check for errors if they happened. For me, the word "safe" also carries the question whether the action could be carried out or not - impossible with having the return as the value return. Especially if it's a generic array, giving you whatever kind of data as a return value. Well, I could just return return an adress, but this kinda destroys the notation. Hm... it would also give less freedom them. Difficult! But I'll play around with this kind of notation. Recently I developed a strong dislike against using methods for accessing objects keeping n elements. Guess I'll also create a special list class that works with operators. I know, I know - I explained my dislike before. But I thought about a while or and came to the point that it's the best to always choose the most understandable notation. And in case of arrays I prefer the C variant with [] brackets. Therefore, other brackets seem to work better than just using functions (on a second note, array(index) seems more usable than array.getSafe(index)...). I thought about using a static variable that's true when the last operation produced an error, but it's not really a clean solution. Many cases come to my mind where it's simply just BAD to do so. Well, I don't know. But I could some kind of array(index,valref) returning bool on success and storing the value in valref... That's by the way to original way I thought for accessing it. Hmmmmmm, really difficult. However, I could also use my event system for that! It'd be an event static for the whole class. So if an error occured, it will notice it. On the other side, this is like exeception handling, which is even more bad that using methods for all the stuff... Well, then let's get back to methods with minimal interface. Guess that's - again - the most flexible but most inconvenient solution. But I'll include the () notation for convenience. I could also simply create a set of events for all possible things to happen and call it if something happens. Due to the fact that you can also simply leave them untouched, you would really not need to worry about them. This (and almost only this) is what I liked about ActionScript: just hook some event for stuff that could happen. Though I think this a nice solution in theory, I know it's always better to check for errors in code cause you can free all previously allocated memory and let the upper layers catch and react correctly. Simple but efficient, always checking for errors when (could) happen and react properly by deallocating and setting all the stuff that's related to the it - that's the way software will work stable and better to debug. I only had good experiences with it and thus the story continues. So what's the schedule now? Use optionally implemented error callbacks but still return true or false on return.

Oh and during the process of writing this I got the final idea: () returns a pointer, thus it's possible to checkfor zero. That's different but you can check for errors this way. And if you really want a more "if(action) then"-style of access, you can use the access methods. Yeah, I think that's an "O.K." way to do it. Let's see what I think is more convenient. Maybe I'll instead use () as an unsafe address access - having [] for references and () for pointers. Don't know. Since I'd use both notation and usually WITHOUT checking for array bounds all the the time (this is done once before execution), this seems a good solution to me.

Hooray for interface design monologues!

No comments: