Héllo,
I have no definitive answer regarding the OOP/functional mismatch.
2014-04-24 18:53 GMT+02:00 tim.thel...@gmail.com:
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,
[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 is,
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 more
On Thu, Apr 24, 2014 at 5:21 PM, tim.thel...@gmail.com 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
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 character
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* the class,
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
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
On Apr 23, 2014 5:01 PM, tim.thel...@gmail.com 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
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
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
On Thu, Apr 24, 2014 at 7:42 AM, Ethan Furman et...@stoneleaf.us 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
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 as a
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
14 matches
Mail list logo
