![]() I use these in my application to find and use the knowledge base, what can be queried in a user project, and what a user can do in the project. It lets a library/pack developer say: "You need to implement this protocol to work with my code". No module system can do this, to distinguish declaration from definition, but it's the mechanism for dependency inversion in Prolog that makes it much easier to share code. Plus you can easily find all objects that implement a protocol. This is really useful for defining interfaces that several objects will promise to keep, like every graphical object promises to have a draw/1 predicate. This is a bit like header files in C, where you say I'm going to have these predicates but they're defined somewhere else. Then you get protocols, which declare predicates but don't define them. I use a category in my application to do reasoning about form responses by importing it into the ~7 forms in the application. ![]() It's nice that you can find all objects that import a category easily. So for example, if you have some defined colour-scheme you might import that into several graphical objects so you only need to change the one colour-scheme, and there's no meaning behind `colour_scheme::draw`, hence a category. A category is some bit(s) of reuseable code that you want several objects to call, but you don't want to call it by itself. Then you get categories that you can import. Very handy, and a lot like subclassing except no need for instantiation. So the first thing you'll use with objects is extension, so if one object extends another it includes all the predicates from the other inside itself. They're different from modules in that they've got stronger encapsulation, differentiate declaration from definition, and work with everything else you'll use. Everything else you use is centered around these simple objects. You define your public and private predicates in them and send messages to them to ask your queries. These are your bread-and-butter in Logtalk. The technical term for it is a prototype, which means it's a self-describing object that exists by itself with no action taken for it to exist. So in Logtalk your basic object is just an object, forget parametric objects for now. noone really uses them unless they really have to. Classes and instantiation are one way to use OO and Logtalk supports them, but they're like the tin in the back of the cupboard you've forgotten about for years. Classes, instantiation, mutation, side-effects, are not OO. OO is just two things: encapsulation and message passing. It seems, like me at first, you're getting confused by the object-oriented languages that are all in the imperitive domain and so muddy what object-oriented really is. They're not even all ISO compliant, nevermind equivalent in predicates & behaviour. And, on the flip side, nearly all the mature Prolog dialects are maintained by a single person with grey hair, so someday I'm going to need to move my code base from one dialect to another. It provides all the tools required to follow the principles of solid architecture. Seperation of declaration from definition let's me share my code easily and seperate libraries out from application. Why? Best testing, documentation, and diagramming tools make it easy for me to understand my code and make sure it's working. I'm probably one of those fans of Logtalk you mention, I became such when (re)-writing and maintaining a ~10,000 line complex application in Prolog. Again, though, I am welcome to hearing what I may be missing here. However, this does not seem like a good mechanism for creating instances of abstract data structures because it is not a pure and declarative operation in particular, the last thing that I want to do in a language like Prolog is to bring in the need to manually manage instances of data structures like I would have to do in an imperative language without garbage collection! So this is the source of much of my confusion because it seems like LogTalk is trying to make it easier to work with data structures but in practice it seems like it does so by turning Prolog into an imperative programming language. This makes sense if it should be viewed as creating a module, because it is a bit like asserting new clauses in the database. The reason for me saying this is that, assuming I understand the documentation correctly, creating a new object is inherently a side-effectful act. From it I get the impression that, rather than thinking of LogTalk as being about object-oriented programming, I should be thinking of it as being a system for writing composable modules, which makes a lot more sense.Īs for abstract data types, I agree that having a nice way to define them would be a boon, but I don't see how LogTalk really helps with this.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |