Fine grained access control to class methods?

One year ago I showed a first picture of Okteta, a successor to KHexEdit in-work. Time to show a new one, here it is:

No changes in the UI of Okteta yet

Well, no big changes in the UI, except for the style and the color. Still looking similar to KHexEdit (which it shall in the default settings, to easen moving over).

But under the hood things are developing. Created a framework called Kakao which serves as a template for programs, so one just needs to plug in factories for documents, views, and tools to get a full featured program for your $datamodel. Currently I am laying grounds for the concept of model synchronizers. Something I have been looking for since ages, really, how can our allday-programs just be without it? Right now I am trying to map the action “Save as…” to it, meaning something like switching the synchronizer, if the remote data model is different (e.g. PNG->JPG for stream formats), or only the location/url. Why is there no option with today’s “Save as…” actions to remove the old remote data model (like old file) BTW? Sometimes one just wants to move/rename a file or recode it, while working on it. Is this workflow so unusual?

An interesting problem is:
How can one limit access to a subset of methods of a class for only certain other classes in C++? I can define friend class Class; for access to all protected methods. But I would like to declare different friends for different subsets of the protected methods. So only the synchronizer classes could call void setRemoteHasChanges( bool hasChanges ); or similar for document subclasses, not some nasty plugin doing dirty things. I imagine I could play some tricks with subclassing abstract classes, but those methods don’t need to be virtual. Is there a better way?

No time to take part in things like Krush Day, me bad boy, I am just too fascinated by the possibilities I see coming with the Kakao framework!


6 thoughts on “Fine grained access control to class methods?

  1. hello,

    One question about oketa: will it load the files you are editing in memory ? If it does, it becomes impossible to edit very large files, and disk partitions and such (unless you have a lot of RAM)


  2. @Frank:
    Yes and no. The currently only fully functional byte array model loads the source completely in memory. It is the quick’n’dirty variant. Another byte array model, which uses a paging mechanism (might later be changed to memory-mapping mechanism of the underlying OS), is currently only readonly. Plans are to make it readwrite, of course. But this is low priority at the moment, and might be outsourced to interested co-developers, once the Kakao framework is more stable. There is no undo/redo right now for example…

  3. about your C++ question: if you want to achieve at compile-time something that can be achieved by using virtual functions, but you don’t want to use virtual functions, what you’re looking for is called the Curiously Recurring Template Pattern (search google/wikipedia).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.