[Newbies] Re: new and initialize

2016-05-11 Thread Joseph Alotta
Sorry, it doesn’t work on the Mac.  The window gets black and then redraws.  I 
think maybe it means “refresh”.

Sincerely,

JOe.



> On May 11, 2016, at 5:07 PM, cbc [via Smalltalk] 
>  wrote:
> 
> Hi.
> 
> On Tue, May 10, 2016 at 12:37 PM, Joseph Alotta <[hidden email]> wrote:
> 
> More questions:  why isn’t there a command key for debug it? 
> 
> I just learned this today - we do have a command key (well, command key 
> sequence) for debug it:
> 
> Shift+Cmd+D to "Debug it"
> 
> -cbc
> 
> ___ 
> Beginners mailing list 
> [hidden email] 
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://forum.world.st/new-and-initialize-tp4894227p4894371.html
> To start a new topic under Squeak - Beginners, email 
> ml-node+s1294792n107673...@n4.nabble.com 
> To unsubscribe from Squeak - Beginners, click here.
> NAML





--
View this message in context: 
http://forum.world.st/new-and-initialize-tp4894227p4894377.html
Sent from the Squeak - Beginners mailing list archive at Nabble.com.___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners


Re: [Newbies] Re: new and initialize

2016-05-11 Thread Chris Cunningham
Hi.

On Tue, May 10, 2016 at 12:37 PM, Joseph Alotta 
wrote:


> More questions:  why isn’t there a command key for debug it?
>

I just learned this today - we do have a command key (well, command key
sequence) for debug it:

Shift+Cmd+D to "Debug it"

-cbc
___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners


RE: [Newbies] Re: new and initialize

2016-05-10 Thread Ron Teitelbaum
 

 

From: Joseph Alotta
Sent: Tuesday, May 10, 2016 3:38 PM



 


> On May 10, 2016, at 12:45 PM, Ron Teitelbaum [via Smalltalk] <[hidden email]> 
> wrote: 
> 
> Hi Joe, 
> 
> Excellent question.  Try this.   
> 
> Object new. 
> 
> Highlight it and do debug it.   Click "Into" to go into the #new method. 
> 
> Notice the implementation of #new.   
> 
> You should be able to see there that #initialize is called automatically. 
>   
> Also for extra points notice what class new is implemented on. 


Behavior 

[Ron Teitelbaum] Exactly!  



>  What method should you call to skip initialize? 

basicNew 

[Ron Teitelbaum] Excellent!



More questions:  why isn’t there a command key for debug it? 

[Ron Teitelbaum] No clue.  


 why isn’t my initialize method not running or running without 
setting variables? 

[Ron Teitelbaum] put a halt in your method and run it.  See if the initialize 
is being called at all.  If it is then check the content of your method for 
errors.  If not then your initialize method is spelled wrong, is not on the 
instance side, or there is a new method implemented in your class or a 
superclass that is bypassing the default implementation of #new which is a bad 
thing.  The system gives you a warning to let you know that!! J

All the best,

Ron




Thank you. 

Sincerely, 

Joe. 




  _  

View this message in context: Re: new and initialize 
 
Sent from the Squeak - Beginners mailing list archive 
  at Nabble.com.

___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners


[Newbies] Re: new vs. initialize

2008-12-10 Thread Zulq Alam

Hi Greg,

My comments are below...

Greg A. Woods; Planix, Inc. wrote:

 Now I read on the WWW that the added sending of #initialize from
 Behaviournew was added in 3.9.

Where did you read this? I've been using Squeak for a few years and as 
far as I know the default implementation of #new has always sent 
#initialize.


The history of Behaviournew shows one version dated 23-8-2003. This is 
well before 3.9.


Just for fun I did a search for senders of #basicNew and I found quite a 
few which are from #new methods in classes which subclass directly from 
Object and which are in classes that also define their own #initialize 
method.  The curious bit is how some of these #new methods do send 
#initialize, but not all.  I'm guessing some that don't are for abstract 
classes, but is it true that all are?


There are a number of reasons one might call #basicNew, e.g. 
compatibility with other dialects, limiting use of #new by signalling an 
error, avoiding the normal initialisation from an alternative 
constructor, etc. In most cases super new would also work.


Those that call intitialize may do so because they still need that 
method to be called, perhaps after doing something else. Some call it 
for compatability...




Also, doesn't this still create an _enormous_ portability problem with 
other Smalltalks?




Have a look at what Seaside and other cross dialect projects do. I 
believe but am not sure they all have some sort of self basicNew 
initialize on all their top level classes.


- Zulq
___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners


Re: [Newbies] Re: new vs. initialize

2008-12-09 Thread Greg A. Woods; Planix, Inc.


On 9-Dec-2008, at 11:26 AM, Tim Johnson wrote:


On Dec 8, 2008, at 8:56 PM, Greg A. Woods; Planix, Inc. wrote:

Initially though this recommendation didn't make any sense to me  
because I didn't know how the implementation of #new in Behaviour  
is different from strict Smalltalk-80 as I understand it.  I.e.  
originally in Smalltalk-80 #new did not also send #initialize, but  
now in Squeak it does.


This recent (!) change to auto-initialize puzzles me as well.  So  
much existing code was written with the opposite case being true,  
that it seems so risky to change!  To diverge from the ST-80  
standard is even more risky, I would think.


Well what really angers me about this change is that it's not properly  
documented in any way shape or form.  There's just the code, and even  
with all the code browsing tools in Squeak it still took me far longer  
than it should have to figure this out.  Part of that was my  
unfamiliarity with Behaviour and ProtoObject, but most of it was the  
total and complete lack of documentation about this difference.  Even  
outside the image itself there's just one very out-of-date page on the  
swiki about this, and it gives no details or proper rationalization  
whatsoever, and indeed it gives caution to some of the issues.  It  
certainly doesn't say it's a done deal -- in fact it's still in the  
improving section.  There's a very long and convoluted thread in the  
mailing list archives but as yet I haven't even read anywhere of any  
true consensus being reached (though many folks just seem to have been  
beaten into submission).


I am annoyed that anyone would want to change this fundamental little  
part of the basic Object protocol too.  #new is supposed to answer a  
new instance of the receiver.  Period.  Not also do any callbacks back  
to any other instance methods.  None.  RTFM.  Maintaining the status  
quo is very important when you're talking about fundamental parts of  
the object protocol.  Now Squeak documents Behaviournew as returning  
a new _initialized_ instance, but that's not (universally) true so  
it's very confusing.


Now every book, every paper, every web page, including tons of  
squeak.org web pages, are now (still) incompatible with the current  
(and previous) release of Squeak.  Squeak is now incompatible with its  
own earlier versions.  Squeak is now incompatible with code that used  
to work in Squeak, and at least one of the classes right in the main  
release, one which is used by a package still in the default package  
universes, has been broken by a naive change (a relatively long time  
ago) by someone who presumably should have known better (i.e. who was  
probably aware of the change to #new) and who obviously didn't test  
their change.


It seems to me that Squeak users _must_ now be experienced developers  
in order to be able to file in old code and actually make it work in  
far too many cases.  I.e. this change is a total failure when it comes  
to supporting _users_.  If I had given out code that somehow relied on  
the old #new protocol and then disappeared now only someone with  
enough experience and knowledge can make use of it in a new Squeak  
release.  Indeed this happens all the time in the world of software,  
all too often.  But that doesn't mean it should happen.  I'm beginning  
to understand why many serious Smalltalk programmers I've met in  
recent years consider Squeak to be no more than a toy.


I'm also beginning to understand why the gurus around me more than 20  
years ago were telling me that default initialization was a Bad  
Thing(tm).  First off, not everything needs to be initialized.  Also,  
as was discussed in some detail before, this most basic form of  
parameter-less initialization doesn't work for probably the majority  
of classes which really do need initialization upon instantiation so  
what exactly is the benefit anyway?  Even the Blue book effectively  
gives caution to why auto-initialization can be very tricky and far  
less helpful than it may at first appear to be (p. 274).


Finally I think that some of the apparent justification for this  
change, a topic that was bandied about on the mailing list way back  
when, is also naive in and of itself.  I'm referring to the claim that  
this change will help educators avoid having to deal with the meta- 
level of how classes are implemented.  Don't get me wrong though --  
I've never taught Smalltalk, this is just from my experience of  
(trying to) learning it.  First off I think the problem with the  
concept of metaclasses in Smalltalk is that they're not exposed  
clearly and plainly enough in the first place.  The chapter(s)  
describing them in sufficient detail comes far too late in all the  
textbooks (especially the original one -- #16!?!?!?!).  The default  
code browsers have never been easily shown metaclass information in  
any decent way that properly lays out the structure and hierarchy of  
metaclasses and