Re: Moving to an OOP model from an classically imperitive one

2014-04-25 Thread Amirouche Boubekki
Héllo, I have no definitive answer regarding the OOP/functional mismatch. 2014-04-24 18:53 GMT+02:00 : > > A reasonable compromise might be to keep the *data* assocated > > > > with a SubuserProgram in a class, maybe together with a few > > > > methods that are tightly coupled to it, but have th

Re: Moving to an OOP model from an classically imperitive one

2014-04-24 Thread tim . thelion
> A reasonable compromise might be to keep the *data* assocated > > with a SubuserProgram in a class, maybe together with a few > > methods that are tightly coupled to it, but have the major > > pieces of functionality such as install() implemented by > > separate functions that operate *on* th

Re: Moving to an OOP model from an classically imperitive one

2014-04-24 Thread Steven D'Aprano
On Thu, 24 Apr 2014 00:21:18 -0700, tim.thelion wrote: >> [snip] >> >> Could you make the program name unique just by combining it with the >> >> repository name in a single string? > > In my case I cannot. But there is a larger reason why I wouldn't do > this: It would mean adding a special

Re: Moving to an OOP model from an classically imperitive one

2014-04-24 Thread Chris Angelico
On Thu, Apr 24, 2014 at 5:21 PM, wrote: >> [snip] >> >> Could you make the program name unique just by combining it with the >> >> repository name in a single string? > > In my case I cannot. But there is a larger reason why I wouldn't do this: > It would mean adding a special character that c

Re: Moving to an OOP model from an classically imperitive one

2014-04-24 Thread tim . thelion
> I'm curious what these practical reasons are. One my smallest source files > has 870 lines in it, my largest nearly 9000. > > > > If the problem is your editor, you should seriously consider switching. > I think that the main reasons for doing so are as follows: git status provides much m

Re: Moving to an OOP model from an classically imperitive one

2014-04-24 Thread tim . thelion
> [snip] > > Could you make the program name unique just by combining it with the > > repository name in a single string? In my case I cannot. But there is a larger reason why I wouldn't do this: It would mean adding a special character that could not be included in the repository name, that

Re: Moving to an OOP model from an classically imperitive one

2014-04-23 Thread Gregory Ewing
Ian Kelly wrote: How about adding one abstract class per file, and then letting SubuserProgram inherit from each of those individual classes? I'd recommend against that kind of thing, because it makes the code hard to follow. With module-level functions, you can tell where any given function

Re: Moving to an OOP model from an classically imperitive one

2014-04-23 Thread Gregory Ewing
tim.thel...@gmail.com wrote: I think this would be better solved by moving fully to an OOP model. That is, I would have a SubuserProgram class which had methods such as "install", "describe", "isInstalled"... This wouldn't necessarily be better. Don't be taken in by the "everything is better a

Re: Moving to an OOP model from an classically imperitive one

2014-04-23 Thread Chris Angelico
On Thu, Apr 24, 2014 at 7:42 AM, Ethan Furman wrote: > On 04/23/2014 01:57 PM, tim.thel...@gmail.com wrote: >> >> >> There is one problem though. Currently, I have these functions logically >> organized into source files, each between 40 and 170 LOC. I fear that if >> I were to put all of these

Re: Moving to an OOP model from an classically imperitive one

2014-04-23 Thread MRAB
On 2014-04-23 21:57, tim.thel...@gmail.com wrote: Hello, I am currently writting a program called subuser(subuser.org), which is written as classically imperative code. Subuser is, essentially, a package manager. It installs and updates programs from repositories. I have a set of source files

Re: Moving to an OOP model from an classically imperitive one

2014-04-23 Thread Ethan Furman
On 04/23/2014 01:57 PM, tim.thel...@gmail.com wrote: There is one problem though. Currently, I have these functions logically organized into source files, each between 40 and 170 LOC. I fear that if I were to put all of these functions into one class, than I would have a single, very large s

Re: Moving to an OOP model from an classically imperitive one

2014-04-23 Thread Ian Kelly
On Apr 23, 2014 5:01 PM, wrote: > I asked on IRC and it was sugested that I use multiple classes, however I see no logical way to separate a SubuserProgram object into multiple classes. You say you already have the methods logically separated into files. How about adding one abstract class per fi

Re: Moving to an OOP model from an classically imperitive one

2014-04-23 Thread Mark Lawrence
On 23/04/2014 21:57, tim.thel...@gmail.com wrote: Hello, I am currently writting a program called subuser(subuser.org), which is written as classically imperative code. Subuser is, essentially, a package manager. It installs and updates programs from repositories. I have a set of source fil

Moving to an OOP model from an classically imperitive one

2014-04-23 Thread tim . thelion
Hello, I am currently writting a program called subuser(subuser.org), which is written as classically imperative code. Subuser is, essentially, a package manager. It installs and updates programs from repositories. I have a set of source files https://github.com/subuser-security/subuser/tree