Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Implicit initialization is EVIL!

Reply
Thread Tools

Implicit initialization is EVIL!

 
 
nn
Guest
Posts: n/a
 
      07-05-2011
On Jul 4, 11:35*am, Robin Becker <(E-Mail Removed)> wrote:
> On 03/07/2011 23:21, Chris Angelico wrote:
> .........
>
> > var(0x14205359) x * # Don't forget to provide an address where the
> > object will be located
> > x=42

>
> ........
> did you forget to specify the memory bank and computer (and presumably planet
> etc etc....)
> -molly-coddled-ly yrs-
> Robin Becker


Ah, I see we have a mainframe programmer among us ...
 
Reply With Quote
 
 
 
 
Web Dreamer
Guest
Posts: n/a
 
      07-05-2011
Steven D'Aprano a écrit ce mardi 5 juillet 2011 16:25 dans
<4e131ef7$0$29977$c3e8da3$(E-Mail Removed) om> :

> Gregory Ewing wrote:
>
>> rantingrick wrote:
>>> Most applications consist of one main window
>>> (a Tkinter.Tk instance).

>>
>> You've obviously never used a Macintosh. On the Mac, it's
>> perfectly normal for an application to open multiple
>> documents, each in its own window, with no one window
>> being the "main" window. Any of them can be closed (or
>> even *all* of them) and the application continues to run
>> until you explicitly quit it.

>
> Or a Linux GUI. I have kwrite running with 15 open windows. The
> application doesn't exit until the last window is closed, and no window is
> privileged over the others.


What he means is that On Mac, if you close "all" windows, the application is
still running.
If you have closed all windows and want to quit an app, you need to click
it's icon (in the dock) or access it via <alt-tab> and explicitly quit it
(in the application's menu, or <cmd-Q>).
Of coarse, for this to work, on Macs, the menu is not in the windows
themselves. The menu is displayed in a menu-bar at the top of the screen,
and changes to match the focussed application.

- Good point about it : If you closed all windows of a heavy application,
you don't need to "relaunch" it to reopen a file (much faster).
- Bad point about it : Most Windows/Linux people I've seen trying a mac for
the first time have lots of apps running, not knowing they didn't close them
(until they ask why their dock is cluttered, or why apps usually in their
dock stay with a "bleu dot" (meaning the app is running)).
Like for every thing else, their are pros and cons.


--
Web Dreamer

 
Reply With Quote
 
 
 
 
Robin Becker
Guest
Posts: n/a
 
      07-05-2011
On 05/07/2011 16:33, nn wrote:
.......
> Ah, I see we have a mainframe programmer among us ...

so long since I manipulated the switches of that old pdp-8
-anciently yrs-
Robin Becker

 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      07-05-2011
On Jul 5, 10:17*am, Chris Angelico <(E-Mail Removed)> wrote:

> It's actually quite easy to implement this, even if you _are_ forced
> to have one primary window. You just have an invisible primary whose
> sole purpose is to "be the application", and then everything else is
> secondary windows. Kinda defeats the purpose of forcing applications
> to have one primary window, though.
>
> To my thinking, there will always be one primary *thread*, and GUI
> facilities are secondary to the process, never the other way around.
> When the main thread exits, the process ends.



Chris are you playing devils advocate (for my team). I am confused?
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      07-05-2011
On Jul 5, 11:00*am, Web Dreamer <(E-Mail Removed)> wrote:

> What he means is that On Mac, if you close "all" windows, the applicationis
> still running.


Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
Let's use the correct lingo people!

 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      07-05-2011
On Jul 5, 6:14*am, Gregory Ewing <(E-Mail Removed)> wrote:
> rantingrick wrote:
> > Most applications consist of one main window
> > (a Tkinter.Tk instance).

>
> You've obviously never used a Macintosh. On the Mac, it's
> perfectly normal for an application to open multiple
> documents, each in its own window, with no one window
> being the "main" window. Any of them can be closed (or
> even *all* of them) and the application continues to run
> until you explicitly quit it.


And how do you EXPLICITY quit the application? Because the interface
for window management(on windows box) is three buttons "minimize",
"maximize", and "destroy". If closing the window only "hides" the
window then you are just "managing" a window's "visibility". We are
talking about destroying GUI processes here.
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      07-05-2011
On Wed, Jul 6, 2011 at 8:42 AM, rantingrick <(E-Mail Removed)> wrote:
> Chris are you playing devils advocate (for my team). I am confused?


I say whatever I choose to say. Don't pigeon-hole me into "on your
team" or "not on your team" or "devil's advocate" or whatever. And at
two in the morning, "whatever I choose to say" can be quite random.

> On Jul 5, 11:00*am, Web Dreamer <(E-Mail Removed)> wrote:
>
>> What he means is that On Mac, if you close "all" windows, the application is
>> still running.

>
> Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
> Let's use the correct lingo people!


Actually, it IS closing those windows. Why wouldn't it be?

1) User presses Alt-F4, or clicks the X, or opens the system menu and
chooses 'Close Window'.
2) Windowing manager sends a message to the appropriate thread's queue
(on MS Windows, that's WM_CLOSE; not sure how on Linux as I haven't
bothered to dig that deep - interface layers like Tkinter and GTK
don't count).
2a) Toolkit passes message to application code, if applicable.
3) Application destroys this window, leaving the other windows alive.

The memory used by that window can be reclaimed. Handles to its
objects are no longer valid. The window really is closed. The
application might not have terminated, but that window has not been
minimized - the *window* is closed.

> And how do you EXPLICITY quit the application? Because the interface
> for window management(on windows box) is three buttons "minimize",
> "maximize", and "destroy". If closing the window only "hides" the
> window then you are just "managing" a window's "visibility". We are
> talking about destroying GUI processes here.


Presumably you would right-click it and choose "Exit" or something. Up
to the application. If all else fails, kill -9 it.

The interface for window management does not actually have "destroy",
it has "close". The normal handling of a close message is to destroy
the window; and in many applications, once all windows have been
destroyed, the process terminates. These are three quite separate
concepts. The separation of "close" and "destroy" is most easily seen
in "Are you sure" prompts - you send a Close signal to the window, but
the application queries you before going through with the destruction.
And even once the last window has been destroyed, that has nothing to
do with process termination.

I could conceivably write a program that sits invisibly in the
background until a network message arrives. Upon receipt of such a
message, the program initializes the GUI subsystem and opens a window.
When the user closes the window, the program flushes all GUI code out
of memory and waits for the next message. While it's waiting, is there
any "main window" that exists but has just been hidden? No. But is the
application still running? Of course! Completely separate.

ChrisA
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      07-05-2011
On Jul 5, 6:20*pm, Chris Angelico <(E-Mail Removed)> wrote:
> On Wed, Jul 6, 2011 at 8:42 AM, rantingrick <(E-Mail Removed)> wrote:
> [...]
> > On Jul 5, 11:00*am, Web Dreamer <(E-Mail Removed)> wrote:
> >> What he means is that On Mac, if you close "all" windows, the application is
> >> still running.

>
> > Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
> > Let's use the correct lingo people!

>
> Actually, it IS closing those windows. Why wouldn't it be?
> [...]
> The memory used by that window can be reclaimed. Handles to its
> objects are no longer valid. The window really is closed. The
> application might not have terminated, but that window has not been
> minimized - the *window* is closed.


And you need the OS to that for you!?!? Are you joking?

> I could conceivably write a program that sits invisibly in the
> background until a network message arrives. Upon receipt of such a
> message, the program initializes the GUI subsystem and opens a window.
> When the user closes the window, the program flushes all GUI code out
> of memory and waits for the next message. While it's waiting, is there
> any "main window" that exists but has just been hidden? No. But is the
> application still running? Of course! Completely separate.


And so could i using Tkinter and it's "supposedly" flawed window
hierarchy. Remind me again why we are discussing this?
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      07-05-2011
On Wed, Jul 6, 2011 at 9:47 AM, rantingrick <(E-Mail Removed)> wrote:
>> > Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
>> > Let's use the correct lingo people!

>>
>> Actually, it IS closing those windows. Why wouldn't it be?
>> [...]
>> The memory used by that window can be reclaimed. Handles to its
>> objects are no longer valid. The window really is closed. The
>> application might not have terminated, but that window has not been
>> minimized - the *window* is closed.

>
> And you need the OS to that for you!?!? Are you joking?
>


To do what for me? Close windows? Reclaim memory? Terminate
applications? I don't understand your bogglement.

ChrisA
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      07-06-2011
On Jul 5, 6:54*pm, Chris Angelico <(E-Mail Removed)> wrote:

> To do what for me? Close windows? Reclaim memory? Terminate
> applications? I don't understand your bogglement.


ClaimA: I made claim that Tkinter's window hierarchy is not only
normal, but justified in modern GUI programming.

ClaimB: You made a claim ( or supported a rebuttal claim) that Mac's
system of window management was superior and did not need such a
"window hierarchy" simply because;

1. You can create a program that twiddles it's thumbs (using very
little memory) until a message is received.
2. Upon receiving a message the program can open a GUI window.
3. When the user closes the GUI window (definition of "close" is not
nailed down yet!) the program will free the GUI memory and start
twiddling it's thumbs again until the next message arrives.
4. rinse and repeat until you are happy.

It's obvious that yours and my claims are contradicting. So with that
said, at what point does Tkinter or Windows fail in this example you
provide? Because, i can recreate the exact same functionality on a
windows box without need of the underlying window manager's help.

1. What is your point?
2. And how does it prove my position incorrect?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Implicit initialization is EXCELLENT Steven D'Aprano Python 18 07-07-2011 03:58 PM
array initialization in initialization list. toton C++ 5 09-28-2006 05:13 PM
Initialization of non-integral type in initialization list anongroupaccount@googlemail.com C++ 6 12-11-2005 09:51 PM
Initialization via ctor vs. initialization via assignment Matthias Kaeppler C++ 2 07-18-2005 04:25 PM
Default Initialization Vs. Value Initialization JKop C++ 10 09-22-2004 07:26 PM



Advertisments