Global in multiple files 
Author Message
 Global in multiple files

I'm not a fan of OO but I decided to give it a try. After all, python
makes it elegant.

So I wrote a program usuing classes, methods etc. All nice. Then it
grew up and I decided to split it in several files - one class into
each class as Guido asked us to do.

And then, I came across my first problem: I had had a global variable
(just one!) and it wouldn't work anymore. At all. Any 'global'
declarations wouldn't help, and without it I'm lost.

So, I thought I might be smarter than it. I would pass this
variable to where I need it, but... it stil obstinately refuses to
work. But then, my ex-global is a list of instances of a class,
and methods in instances of another class won't accept it as
an argument.

So, any ideas how I should cope with that and be able to use my
global variable in different clases in different files?

Regards,
Artur
--
http://www.*-*-*.com/

"Jakos nie kusi mnie perspektywa zostania wsiowym glupkiem
znajacym sie tylko na komputerach i zarabiajacym mnostwo kasy" -- lcamtuf



Thu, 27 Nov 2003 19:21:09 GMT  
 Global in multiple files

Quote:
>I'm not a fan of OO but I decided to give it a try. After all, Python
>makes it elegant.

>So I wrote a program usuing classes, methods etc. All nice. Then it
>grew up and I decided to split it in several files - one class into
>each class as Guido asked us to do.

>And then, I came across my first problem: I had had a global variable
>(just one!) and it wouldn't work anymore. At all. Any 'global'
>declarations wouldn't help, and without it I'm lost.

Probably, you have 3 different globals: one per module.

Quote:
>So, I thought I might be smarter than it. I would pass this
>variable to where I need it, but... it stil obstinately refuses to
>work. But then, my ex-global is a list of instances of a class,
>and methods in instances of another class won't accept it as
>an argument.

Why do you need global variable in the OOP design anyway?
Maybe, it belongs to os.environ or some container class?

I blame myself each time I maintain code with global variables:
the code can't be easily reconfigured, creates other problems.
Globals are allright only in short scripts which has no chance
to grow larger.

Quote:
>So, any ideas how I should cope with that and be able to use my
>global variable in different clases in different files?

>Regards,
>Artur

Sincerely yours, Roman Suzi
--

_/ Sunday, June 10, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Computers make very fast, very accurate mistakes." _/


Thu, 27 Nov 2003 21:21:18 GMT  
 Global in multiple files

Quote:

>>So, I thought I might be smarter than it. I would pass this
>>variable to where I need it, but... it stil obstinately refuses to
>>work. But then, my ex-global is a list of instances of a class,
>>and methods in instances of another class won't accept it as
>>an argument.

>Why do you need global variable in the OOP design anyway?

I knew you would say that! ;)
The source code is at http://arturs.iidea.pl/server.py
and you can get 'live demo' by
$ telnet arturs.iidea.pl 2211
It's based on simple chat code.

I just want to keep this one little global, userlist, in order
not to do some strange acrobatics later. It's clean, simple,
keeps the number of arguments to pass to ther functions small etc.

Quote:
>I blame myself each time I maintain code with global variables:
>the code can't be easily reconfigured, creates other problems.
>Globals are allright only in short scripts which has no chance
>to grow larger.

In this case it fits perfectly. I need to acces userlist from any place,
any moment.

OK, suppose I want to do away with global userlist.
I want to pass it to TS_Command instance. Will it work? No. Why?
I have no idea... You see, I don't want to stick fanatically to my
global, any solution is fine, provided that I can split my code
and see it working as before, when it was all in one file.
This 'userlist' is my last obstacle.

Regards,
Artur
--
http://www.wolneprogramy.org

"Jakos nie kusi mnie perspektywa zostania wsiowym glupkiem
znajacym sie tylko na komputerach i zarabiajacym mnostwo kasy" -- lcamtuf



Thu, 27 Nov 2003 22:58:53 GMT  
 Global in multiple files

Quote:
>>Why do you need global variable in the OOP design anyway?

>I knew you would say that! ;)

Yes, of course. Because in True Object Design there is no place for
anything global. You have to make some class instance of which will manage
userlist.

Quote:
>The source code is at http://arturs.iidea.pl/server.py
>and you can get 'live demo' by
>$ telnet arturs.iidea.pl 2211
>It's based on simple chat code.

>I just want to keep this one little global, userlist, in order
>not to do some strange acrobatics later. It's clean, simple,
>keeps the number of arguments to pass to ther functions small etc.

After seven years of trial and error I could say that I begin to
understand OOP ;-)

I thought that way about arguments too. It only says that your object
design is not done right way. (It usually happens when it's first try
anyway).

Quote:
>>I blame myself each time I maintain code with global variables:
>>the code can't be easily reconfigured, creates other problems.
>>Globals are allright only in short scripts which has no chance
>>to grow larger.

>In this case it fits perfectly. I need to acces userlist from any place,
>any moment.

Maybe some object could be used to represent the functionality with a
proper method. For example, AuthoriseUser(). It's a singleton in your
situation. But if later you decide to have more userlists, you could add
it to authorisation chain.

Quote:
>OK, suppose I want to do away with global userlist.
>I want to pass it to TS_Command instance. Will it work? No. Why?

You still think in terms of structural design. Even modular design already
has some precautions against globals. Objects are here to completely
eliminate the problem.

Quote:
>I have no idea... You see, I don't want to stick fanatically to my
>global, any solution is fine, provided that I can split my code
>and see it working as before, when it was all in one file.
>This 'userlist' is my last obstacle.

It's not. It's just first iteration of object analysis/design/programming
you did. (In fact, your classes has hard-coded many things. Probably you
will want to change this in the future.)

It's real fun to return to the same design after some time
and look at it critically.

Thus, I do not critisize you here. I am trying to express what I myself
felt when I tried to reimplement something with objects. At first try
you have objects wrong. (This is seen from the amount of cross-usages).

It's a painful process which decreeses quality of the code at first. But
then it starts to pay off. Bad object design is worse than bad structural
one, someone said, but good OD is better than good structural.

Try to rethink your design. Maybe your code will have other
classes than you have now, and will be less lines.

Quote:
>Regards,
>Artur

Sincerely yours, Roman Suzi
--

_/ Sunday, June 10, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Computers make very fast, very accurate mistakes." _/


Fri, 28 Nov 2003 01:55:17 GMT  
 Global in multiple files

Quote:

> So, any ideas how I should cope with that and be able to use my
> global variable in different clases in different files?

Create a separate module, say globalVar.py, and put your globals into that
(it should set their initial values. E.g. myList = [ ]; myStuff = None).
Then use:

import globalVar

at the top of all your modules that need to access/update the globals. In
your code you then just reference as, say, globalVar.myList.append('some
value'), globalVar.myStuff = 3, etc. All your modules can now access and
update the global variables as needed and their global nature is also self
documented.

Hope this helps!



Fri, 28 Nov 2003 02:14:27 GMT  
 Global in multiple files

Quote:

> >>Why do you need global variable in the OOP design anyway?

> >I knew you would say that! ;)

> Yes, of course. Because in True Object Design there is no place for
> anything global.

That's a silly philosophy.  Classes are objects; are they allowed to be
global?  What about objects that provide a higher level of abstraction than
classes?

--

Shareware computer games           -           http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor



Fri, 28 Nov 2003 04:01:36 GMT  
 Global in multiple files

Quote:


>>>Why do you need global variable in the OOP design anyway?

>>I knew you would say that! ;)

>Yes, of course. Because in True Object Design there is no place for
>anything global. You have to make some class instance of which will manage
>userlist.

Mhm. It seems a little too much overhed for a simple list of users.
The problem is I need it in many places. So even if I create class
ManageUsers, set userlist=ManageUsers(), then userlist.add(user),
it will not solve my problem - it might solve for one class only,
so probably I need to rearange everything.

Quote:
>>I just want to keep this one little global, userlist, in order
>>not to do some strange acrobatics later. It's clean, simple,
>>keeps the number of arguments to pass to ther functions small etc.

>After seven years of trial and error I could say that I begin to
>understand OOP ;-)

>I thought that way about arguments too. It only says that your object
>design is not done right way. (It usually happens when it's first try
>anyway).

The problem is how to do it in this case? It seems this is not
exactly within the scope of this group. But the necessity of
having userlist available from (almost) everywhere seems still
obvious to me.

Quote:
>>>I blame myself each time I maintain code with global variables:
>>>the code can't be easily reconfigured, creates other problems.
>>>Globals are allright only in short scripts which has no chance
>>>to grow larger.

>>In this case it fits perfectly. I need to acces userlist from any place,
>>any moment.

>Maybe some object could be used to represent the functionality with a
>proper method. For example, AuthoriseUser(). It's a singleton in your
>situation. But if later you decide to have more userlists, you could add
>it to authorisation chain.

No, that part of the code (authorisation etc.) is not important now.
It all will be rewritten, anyway. But I need to be able to know
the value of userlist from within instances of TS_Command.Handle(),
also from my main module, and - because the project is a little
specific - from TS_System and maybe some other classes.
So some solution would be to pass userlist as an argument of TS_Command
instance, but somehow it won't work.

Quote:
>>OK, suppose I want to do away with global userlist.
>>I want to pass it to TS_Command instance. Will it work? No. Why?

>You still think in terms of structural design. Even modular design already
>has some precautions against globals. Objects are here to completely
>eliminate the problem.

Tell me how :) I think maybe I', stuck against some exception
- I really need this list everywhere...

Quote:
>>I have no idea... You see, I don't want to stick fanatically to my
>>global, any solution is fine, provided that I can split my code
>>and see it working as before, when it was all in one file.
>>This 'userlist' is my last obstacle.

>It's not. It's just first iteration of object analysis/design/programming
>you did. (In fact, your classes has hard-coded many things. Probably you
>will want to change this in the future.)

For sure - I'm jus experimeting, it will al be rewritten, maybe
in another language, I just want to check out different ways
(Ruby seems elegant, also I spare some finger-gimnastics when
I have to change indentation of a whole function only because I
added one condition etc.)

Quote:
>It's real fun to return to the same design after some time
>and look at it critically.

>Thus, I do not critisize you here. I am trying to express what I myself
>felt when I tried to reimplement something with objects. At first try
>you have objects wrong. (This is seen from the amount of cross-usages).

>It's a painful process which decreeses quality of the code at first. But
>then it starts to pay off. Bad object design is worse than bad structural
>one, someone said, but good OD is better than good structural.

>Try to rethink your design. Maybe your code will have other
>classes than you have now, and will be less lines.

Could you suggest some good books about OO?
I want to make things easy for someone who might want to add
functionality to that code, so it must not be ugly.

(BTW I would like to thank other people for pointing out the
possibility of having global.py module etc. Yes, it solves my
problem for now, but maybe I should really redesign it as Roman
suggest to eliminate the need. No, I still don't know how :))

Regards,
Artur
--
http://www.wolneprogramy.org

"Jakos nie kusi mnie perspektywa zostania wsiowym glupkiem
znajacym sie tylko na komputerach i zarabiajacym mnostwo kasy" -- lcamtuf



Fri, 28 Nov 2003 04:12:51 GMT  
 Global in multiple files

Quote:

> (BTW I would like to thank other people for pointing out the
> possibility of having global.py module etc. Yes, it solves my
> problem for now, but maybe I should really redesign it as Roman
> suggest to eliminate the need. No, I still don't know how :))

I would advise against putting any effort into removing a single global; it
is not be worth your while. In fact there is nothing "wrong" with globals
per se (speaking from ~26 years of programming experience). Don't worry
about removing globals, concentrate instead on containment relationships.
Some "top level" objects and relationships properly belong in the global
name space.

P.S. The main execution frame must start from some name space, normally
called the "global" namespace. So at least one (and usually more) object
references must be contained in it. You can't get around that basic
requirement no matter how much object oriented analysis you care to do.

P.P.S. I've never been able to figure out why people insist on keeping the
global name space as free of objects as possible while not applying that
obsession to other name spaces. True, beginners tend to put everything in
the global name space, but no insight on how to organize relationships is
going to be imparted by telling them not to put things in the global name
space. There is a point when that kind of 30-second "wisdom" becomes unwise.



Fri, 28 Nov 2003 05:34:42 GMT  
 Global in multiple files

Quote:




>> >>Why do you need global variable in the OOP design anyway?

>> >I knew you would say that! ;)

>> Yes, of course. Because in True Object Design there is no place for
>> anything global.

>That's a silly philosophy.

That was said with irony. There is always TheUniverse object.
It is global, depending on philosophy and religion ;-)

Quote:
>Classes are objects; are they allowed to be global?

Classes belong to meta-system, which serves the purpose
of description of the system. That's why classes are
usually global. At least at the module level.

Quote:
>What about objects that provide a higher level of abstraction than
>classes?

The same.

Quote:
>--

>Shareware computer games           -           http://rainerdeyke.com
>"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor

Sincerely yours, Roman Suzi
--

_/ Monday, June 11, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Useless Invention: Fur sink." _/


Fri, 28 Nov 2003 10:51:09 GMT  
 Global in multiple files

Quote:


>>>>Why do you need global variable in the OOP design anyway?

>>>I knew you would say that! ;)

>>Yes, of course. Because in True Object Design there is no place for
>>anything global.

that was an irony...

Quote:
>You have to make some class instance of which will manage
>>userlist.
>Mhm. It seems a little too much overhed for a simple list of users.

What if one day you decide to use threads and userlist is to be shared.
How do you manage your list without breaking it then? But if some object
will be in charge of this resource, it will be much-much easier. You will
need blocking written only once.

Quote:
>The problem is I need it in many places. So even if I create class
>ManageUsers, set userlist=ManageUsers(), then userlist.add(user),
>it will not solve my problem - it might solve for one class only,

Why? You can have userlist static, if you want to:

--- user_manager.py
class UserManager:
  userlist = []
  def __init__(): ...
  def add(): ...
  def poll(self, func ...):
  def get(self): ...
  def iterate(self): ...

--- other module

import user_manager

class TS:
  userlist = user_manager.UserManager()
  ...

Quote:
>so probably I need to rearange everything.

Not much. As a bonus you will get proper defined operations on
userlist.

Quote:
>>>I just want to keep this one little global, userlist, in order
>>>not to do some strange acrobatics later. It's clean, simple,
>>>keeps the number of arguments to pass to ther functions small etc.
>>After seven years of trial and error I could say that I begin to
>>understand OOP ;-)

>>I thought that way about arguments too. It only says that your object
>>design is not done right way. (It usually happens when it's first try
>>anyway).

>The problem is how to do it in this case? It seems this is not
>exactly within the scope of this group. But the necessity of
>having userlist available from (almost) everywhere seems still
>obvious to me.

Then let every class to have it (as I show above, for example).

It is also probably that places it is used "everywhere"
are natural to be included in UserManager class.

OOP is about regrouping code according to entities.

For example, userlist is IMHO natural container for
TS_User's. But it seems you need more than
just contain list of users: you do other operations
on the list: poll users, add users (more complex than
just list.append()).

Quote:
>>>In this case it fits perfectly. I need to acces userlist from any place,
>>>any moment.

>>Maybe some object could be used to represent the functionality with a
>>proper method. For example, AuthoriseUser(). It's a singleton in your
>>situation. But if later you decide to have more userlists, you could add
>>it to authorisation chain.

>No, that part of the code (authorisation etc.) is not important now.
>It all will be rewritten, anyway. But I need to be able to know
>the value of userlist from within instances of TS_Command.Handle(),
>also from my main module, and - because the project is a little
>specific - from TS_System and maybe some other classes.
>So some solution would be to pass userlist as an argument of TS_Command
>instance, but somehow it won't work.
>>>OK, suppose I want to do away with global userlist.
>>>I want to pass it to TS_Command instance. Will it work? No. Why?

>>You still think in terms of structural design. Even modular design already
>>has some precautions against globals. Objects are here to completely
>>eliminate the problem.

Only environment (may also be seen as special object) could be
global. Everything else under the sun isn't ;-)

Quote:
>Tell me how :) I think maybe I', stuck against some exception
>- I really need this list everywhere...

It's interesting, that everywhere could suffer some
drastical rearrangements if you do it in objects.

Small script could bloat. OOP is a code-compressor only when the
complexity is large enough. just like file compressors necessary enlarge
little files (and most of other files too), to be able to compress some of
the files.

Quote:
>>>I have no idea... You see, I don't want to stick fanatically to my
>>>global, any solution is fine, provided that I can split my code
>>>and see it working as before, when it was all in one file.
>>>This 'userlist' is my last obstacle.

>>It's not. It's just first iteration of object analysis/design/programming
>>you did. (In fact, your classes has hard-coded many things. Probably you
>>will want to change this in the future.)

>For sure - I'm jus experimeting, it will al be rewritten, maybe
>in another language, I just want to check out different ways
>(Ruby seems elegant, also I spare some finger-gimnastics when
>I have to change indentation of a whole function only because I
>added one condition etc.)

It's not a problem: you can use Python-aware text editor
or editor with python mode. For code to be readable
indentation is usually a must. So, you indent anyway.

- Show quoted text -

Quote:
>>It's real fun to return to the same design after some time
>>and look at it critically.

>>Thus, I do not critisize you here. I am trying to express what I myself
>>felt when I tried to reimplement something with objects. At first try
>>you have objects wrong. (This is seen from the amount of cross-usages).

>>It's a painful process which decreeses quality of the code at first. But
>>then it starts to pay off. Bad object design is worse than bad structural
>>one, someone said, but good OD is better than good structural.

>>Try to rethink your design. Maybe your code will have other
>>classes than you have now, and will be less lines.

>Could you suggest some good books about OO?
>I want to make things easy for someone who might want to add
>functionality to that code, so it must not be ugly.

Try "OOP tutorial" on google.com

Quote:
>(BTW I would like to thank other people for pointing out the
>possibility of having global.py module etc. Yes, it solves my
>problem for now, but maybe I should really redesign it as Roman
>suggest to eliminate the need. No, I still don't know how :))

Some hints:

TS_Command could be rearranged to provide generic way to
add new commands. For example,

class TS_Command:
  ...

class TS_ls(TS_Command):
  name = "ls"
  def __init__(self...):
  def do(self, args):
    # ls implementation

class TS_pwd(TS_Command):
  name = "pwd"
  def __init__(self...):
  def do(self, args):
    # ls implementation

...

Or at least make

if cond1:
  ...
elif cond2:
  ...

to make your code more effective.

I have not understood what for do you have TS_fs class.
It's just two utilities which could be fine in separate module,
without making a class.

*

I think that probably it's simpler to start from
structural version again.

Your example is not large enough to bother with classes/
objects unless you plan to make it a module for many developers
or plan to grow it into more elaborate system. Of course,
this is good as exercise in OOA/D/P.

I hope my hints help to refine the code.

Quote:
>Regards,
>Artur

Sincerely yours, Roman Suzi
--

_/ Monday, June 11, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Useless Invention: Fur sink." _/


Fri, 28 Nov 2003 10:45:51 GMT  
 Global in multiple files

    ...

Quote:
> >Mhm. It seems a little too much overhed for a simple list of users.

> What if one day you decide to use threads and userlist is to be shared.
> How do you manage your list without breaking it then? But if some object
> will be in charge of this resource, it will be much-much easier. You will
> need blocking written only once.

There is a serious risk in over-designing systems "because
one day it might be handy".  Yeah, right, but meanwhile you're
paying the price of complexity *RIGHT NOW*!-)

"Do the simplest thing that could possibly work", because
"you ain't gonna need it" (where "it" is the rich, complex,
over-engineered, over-designed very general solution:-).

See http://c2.com/cgi/wiki?YouArentGonnaNeedIt ...

Alex



Fri, 28 Nov 2003 16:55:53 GMT  
 Global in multiple files

Quote:



>    ...
>> >Mhm. It seems a little too much overhed for a simple list of users.

>> What if one day you decide to use threads and userlist is to be shared.
>> How do you manage your list without breaking it then? But if some object
>> will be in charge of this resource, it will be much-much easier. You will
>> need blocking written only once.

>There is a serious risk in over-designing systems "because
>one day it might be handy".  Yeah, right, but meanwhile you're
>paying the price of complexity *RIGHT NOW*!-)

I always try to choose more flexible way as long as
it doesn't add to complexity. When it is style of
thinking, it doesn't require much overhead to always
code more generally than is required "right now".
I have too much work "right now" to mend things
which were somebody's "right yesterday".

Somehow, more general solutions do not always require
more work or mean more complexity, but are of better
quality.

Quote:
>"Do the simplest thing that could possibly work", because
>"you ain't gonna need it" (where "it" is the rich, complex,
>over-engineered, over-designed very general solution:-).

That is why Microsoft systems still have those funny
A:, B:, C: letters before file paths ;-)
Because "right yesterday" 640K was enough for everything.

Quote:
>See http://c2.com/cgi/wiki?YouArentGonnaNeedIt ...

>Alex

Sincerely yours, Roman Suzi
--

_/ Monday, June 11, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Useless Invention: Fur sink." _/


Fri, 28 Nov 2003 21:39:51 GMT  
 Global in multiple files
    ...

Quote:
> >There is a serious risk in over-designing systems "because
> >one day it might be handy".  Yeah, right, but meanwhile you're
> >paying the price of complexity *RIGHT NOW*!-)

> I always try to choose more flexible way as long as
> it doesn't add to complexity. When it is style of

If it adds NO complexity, why, sure.  It just
doesn't work that way _most often_, though.  The
natural temptation of the battle-scarred designer
is to overdesign "just in case" -- because the
hundred times where simple design had to be extended
later apparently burn themselves in our neural
circuits more than the thousand times where rich
and complex design just didn't pull its weight
and never really provided any added value.

Quote:
> >"Do the simplest thing that could possibly work", because
> >"you ain't gonna need it" (where "it" is the rich, complex,
> >over-engineered, over-designed very general solution:-).

> That is why Microsoft systems still have those funny
> A:, B:, C: letters before file paths ;-)

Nope, this has absolutely nothing to do with it.  Backwards
compatibility with externally-visible interfaces to previous
releases of your software (and older software you choose
to be similar/compatible to: CP/M, in Microsoft's case) are
(as should be obvious -- I'm amazed I have to point this out)
a completely different issue.

Want to see Microsoft-based examples of over-design versus
simplicity?  Just look at the sheer amount of "reserved,
must be 0" parameters in their Win32 API's.  By far most
of those parameters have been mandatory zeros for close
to ten years now -- and meanwhile the places that would
have needed extra options didn't have them, so we have a
zillion cases of UglyMultiWordNameEx2.  Unix syscalls are
spare and functional, and have withstood the test of time
much more effectively than kernel-Win32 API's (despite
the notorious "I should have spelled 'creat' with an e"
admission of a design error by Thompson:-).

But, again, the issue of externally-exposed interfaces
is quite different from that of implementation architecture.
When you publish an interface, if your program meets with
any success, that interface has to stay forever.  When
you make a design choice regarding your implementation,
you're NOT etching anything into stone -- and that is
what we're talking about here: whether to use a simple
global list, to do the job of a simple global list, OR
overdesign and overarchitect a whole subsystem to take
the place of the simple, obvious approach.

Want more examples?  Of course they'll again be from
the real of externally-exposed interfaces, because that
is where it's easier to share them:-), but that's OK,
since if some simple architecture works well in a
relatively unfavourable case (externally exposed itf)
it will work even better in favourable ones (internal
implementation choices).  How does Python let you know
what built-in modules it has?  A simple global list,
sys.builtin_module_names.  How does it let you know
what arguments your program was called with?  A simple
global list, sys.argv.  How does it let you know AND
AFFECT where modules will be imported from?  A simple
global list, sys.path.  How does it let you know what
modules have been imported os far?  A simple global
_dictionary_ (aha, a variant!-), sys.modules.

Simplicity WORKS WELL.  Simplicity is the backbone of
Python, what really makes it great -- wonderful to
use, powerful AND easy, peerless.  Want to learn to
design programs really well?  You could do worse than
to study what Guido and friends did in Python.  You
will find the small errors and debatable decisions,
you will find the huge numbers of "just right" design
choices, large and small.  Notice how many times those
"just right" choices end up delivering *SIMPLICITY*
over and over again...!-)

Quote:
> Because "right yesterday" 640K was enough for everything.

Furthermore, the choice of drive-letters for file paths,
and the issue of amount of addressable memory, are also
quite obviously independent.  As, again, this is utterly
obvious, I do not understand why you appear to assert
causal dependency between these design choices ('Because'?!).

Quote:
> >See http://c2.com/cgi/wiki?YouArentGonnaNeedIt ...

I reiterate this advice... the Wiki is really a good
place to see these issues discussed -- as open to all
sides as a newsgroup, but building up to more permanent
documents... but not so permanent that you can't always
enhance them (be it only with your questions and open
issues).

Alex



Fri, 28 Nov 2003 22:27:34 GMT  
 Global in multiple files

Quote:
Alex Martelli writes:
> There is a serious risk in over-designing systems "because
> one day it might be handy".  Yeah, right, but meanwhile you're
> paying the price of complexity *RIGHT NOW*!-)
> "Do the simplest thing that could possibly work", because
> "you ain't gonna need it" (where "it" is the rich, complex,
> over-engineered, over-designed very general solution:-).
> See http://c2.com/cgi/wiki?YouArentGonnaNeedIt ...

I agree.  And while you're there, check out the other Extreme Programming
principles.  To me, the thing that makes this principle "work" is its
combination with the other principles (most directly "Refactor
Mercilessly").

Also, remember that "simplest thing" doesn't mean "the first thing that
comes to mind".  It can take some serious contemplation to come up with the
simplest thing.  Einstein's advice is also useful here: "make things as
simple as possible, but no simpler".

--
Don Dwiggins                    "'Tis a gift to be simple,
Advanced MP Technology           'tis a gift to be free..."



Sat, 29 Nov 2003 01:26:23 GMT  
 Global in multiple files
    ...

Quote:
> > There is a serious risk in over-designing systems "because
> > one day it might be handy".  Yeah, right, but meanwhile you're
> > paying the price of complexity *RIGHT NOW*!-)

> > "Do the simplest thing that could possibly work", because
> > "you ain't gonna need it" (where "it" is the rich, complex,
> > over-engineered, over-designed very general solution:-).

> > See http://c2.com/cgi/wiki?YouArentGonnaNeedIt ...

> I agree.  And while you're there, check out the other Extreme Programming
> principles.  To me, the thing that makes this principle "work" is its
> combination with the other principles (most directly "Refactor
> Mercilessly").

The synergy between the various XP principles and practices is
one of its most interesting aspects.  Pairwise programming feeds
into simplicity-seeking, exhaustive testing secures refactoring
isn't breaking things, etc.

But the risk of over-ambitious, over-general design is not one
that XP "invented" (or even "discovered":-) -- it's there all the
time.  Simplicity and refactoring are XP's recipes against this
risk, but the risk is there no matter what (indeed, it's surely
higher the heavier and more invasive your process... in any
sort of design-it-all-up-front "waterfall", it's _ruinous_:-).

Quote:
> Also, remember that "simplest thing" doesn't mean "the first thing that
> comes to mind".  It can take some serious contemplation to come up with
the
> simplest thing.  Einstein's advice is also useful here: "make things as
> simple as possible, but no simpler".

No doubt.  Some are born to simplicity, some have simplicity
thrust upon them... and some *achieve* simplicity with much
toil.  But remember the specifics of what we're talking about:
taking a simple list and overgeneralizing it into an ambitious
"user-administration subsystem" (and this, *WITHOUT* solving
the issue that the original poster had asked about...!-).

Alex

_________________________________________________________
Do You Yahoo!?



Sat, 29 Nov 2003 03:00:40 GMT  
 
 [ 22 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Multiple edits, multiple files

2. Multiple textures on one IndexFaceSet [multiple files, not a map]

3. TCLLib cmdline - multiple file names and multiple invocations

4. use of global variable with multiple state machines and loops

5. How to Set multiple Global Variables without using Controls or Indicators

6. Multiple interpreters and the global lock

7. Global variables in FILE declaration, FILE references; C4b

8. Parsing CSV file outputting desired information into multiple unique files

9. print multiple files from one source file

10. Multiple files with the same file definition

11. ODBC to COBOL-vision-files fails on files with multiple fields

12. One file definition - multiple DOS files

 

 
Powered by phpBB® Forum Software