[vwnc] Epigent AlphaChannelImage

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[vwnc] Epigent AlphaChannelImage

Maarten Mostert-2
Hi

The Epigent package is easy to implement and  makes the toolbar look a good deal better.
 
However on OSX it does not produce the same effect.


<a href="cid:part2.00020104.05050404@wanadoo.fr">              <a href="cid:part2.00020104.05050404@wanadoo.fr">  


Does anyone has dealt with this ?

Regards,

@+Maarten,



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

capture2.tiff (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Epigent AlphaChannelImage

Travis Griggs-3

On Apr 14, 2008, at 3:38 PM, Maarten Mostert wrote:

> Hi
>
> The Epigent package is easy to implement and  makes the toolbar look  
> a good deal better.
>
> However on OSX it does not produce the same effect.
>
>
> <Capturer1.PNG>              <capture2.png>
>
>
> Does anyone has dealt with this ?

Different (display) platforms place A byte in different sequence  
relative to the RGB ones. I assume it's out of order.

--
Travis Griggs
Objologist
"You A students, you'll be back soon teaching here with me. You B  
students, you'll actually go on to be real engineers. You C students,  
you'll go into management and tell the A and B students what to do." -  
My Fluid Dynamics Professor whom I have yet to disprove


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Epigent AlphaChannelImage

Runar Jordahl
In reply to this post by Maarten Mostert-2

I am the author of this package, and I would be happy to try and help you correct these problems. Sadly, I do not own a Mac myself but we can maybe sort this out anyway. As Travis notes, byte order might be the problem. I will contact you later (outside this group).

Runar Jordahl

2008/4/14, Maarten Mostert <[hidden email]>:
Hi

The Epigent package is easy to implement and  makes the toolbar look a good deal better.
 
However on OSX it does not produce the same effect.


<a onclick="return top.js.OpenExtLink(window,event,this)" href="https://mail.google.com/mail/?ui=1&amp;attid=0.0.1.2&amp;disp=emb&amp;view=att&amp;th=1194e76ea198b9b8" target="_blank">              <a onclick="return top.js.OpenExtLink(window,event,this)" href="https://mail.google.com/mail/?ui=1&amp;attid=0.0.1.2&amp;disp=emb&amp;view=att&amp;th=1194e76ea198b9b8" target="_blank">  


Does anyone has dealt with this ?

Regards,

@+Maarten,


 

_______________________________________________
vwnc mailing list
[hidden email]
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.cs.uiuc.edu/mailman/listinfo/vwnc" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/vwnc




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Epigent AlphaChannelImage

Runar Jordahl
In reply to this post by Maarten Mostert-2
I looked at this problem using an example Thomas sent me. Using the
image (provided as Smalltalk code) I reproduced the problem at 16 bit
color depth at my PC. But using my own test image, the problem does
not occur.

To get my test image inspect: AlphaChannelImage iconExample16by16image

Anyone having problems should probably look at this image and see if
it displays ok. Note how the first top-left three pixels are Red,
Green, and Blue. The PNG is attached.

What I found is that Thomas' supplied a Depth32Image that uses a
different palette than I use in my tests. Thomas' Depth32Image has
this palette:
(Graphics.FixedPalette
redShift: 16 redMask: 255
greenShift: 8 greenMask: 255
blueShift: 0 blueMask: 255)



While, my Depth32Image has this palette:
(Graphics.FixedPalette
redShift: 0 redMask: 255
greenShift: 8 greenMask: 255
blueShift: 16 blueMask: 255)

Note how my palette shifts the RGB bits in increasing order; R is at
bit position 0, G at 8, and B at 16. I am pretty sure this is causing
the problems, but I have not looked into the details of the rendering
code to confirm this. So there is a bug in the code, which I will look
at later.

The workaround is to always use a Depth32Image with the palette format
I use in my examples. To create an image I do the following:

- Edit the image in Paint.NET.
- Save the image as PNG in 32 bit format.
- Create the Depth32Image using class PNGImageReader. I use instance
method #from: where the argument is the raw PNG image file as a
Stream.

See references to method  #iconExample16by16 for the details. Note how
#iconExample16by16 answers only a ByteArray which is an exact copy of
the bytes found in the PNG file I saved from the image editing
program. This uses "Epigent File In Method". (
http://www.cincomsmalltalk.com/publicRepository/Epigent%20File%20In%20Method(Bundle).html
)

Runar

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

iconExample16by16.png (862 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Epigent AlphaChannelImage

Thomas Brodt
Hi Runar

Well, this brings some more light into the issue for me. I didn't get to
the idea that the swapping of red and blue could be caused by the
palette used for the images.

One thing that could be a source of this problem could be the import of
our images. I want to check this. I have written an ICO file format
importer because we (some time ago) started to create icons using a
windows icon tool that produces .ico files. Now we additionally use a
bought stock icon library. In the beginning, we produced OpaqueImages
from the ico, and then extended this to create AlphaChannelImages from
32bit ico file format with alpha channel support.

What I want to check is that the import of the ico files produces the
correct results. I even assume that I could change the import and use a
palette that matches yours. That way the issue would just vanish.

Thomas

Runar Jordahl schrieb:

> I looked at this problem using an example Thomas sent me. Using the
> image (provided as Smalltalk code) I reproduced the problem at 16 bit
> color depth at my PC. But using my own test image, the problem does
> not occur.
>
> To get my test image inspect: AlphaChannelImage iconExample16by16image
>
> Anyone having problems should probably look at this image and see if
> it displays ok. Note how the first top-left three pixels are Red,
> Green, and Blue. The PNG is attached.
>
> What I found is that Thomas' supplied a Depth32Image that uses a
> different palette than I use in my tests. Thomas' Depth32Image has
> this palette:
> (Graphics.FixedPalette
> redShift: 16 redMask: 255
> greenShift: 8 greenMask: 255
> blueShift: 0 blueMask: 255)
>
>
>
> While, my Depth32Image has this palette:
> (Graphics.FixedPalette
> redShift: 0 redMask: 255
> greenShift: 8 greenMask: 255
> blueShift: 16 blueMask: 255)
>
> Note how my palette shifts the RGB bits in increasing order; R is at
> bit position 0, G at 8, and B at 16. I am pretty sure this is causing
> the problems, but I have not looked into the details of the rendering
> code to confirm this. So there is a bug in the code, which I will look
> at later.
>
> The workaround is to always use a Depth32Image with the palette format
> I use in my examples. To create an image I do the following:
>
> - Edit the image in Paint.NET.
> - Save the image as PNG in 32 bit format.
> - Create the Depth32Image using class PNGImageReader. I use instance
> method #from: where the argument is the raw PNG image file as a
> Stream.
>
> See references to method  #iconExample16by16 for the details. Note how
> #iconExample16by16 answers only a ByteArray which is an exact copy of
> the bytes found in the PNG file I saved from the image editing
> program. This uses "Epigent File In Method". (
> http://www.cincomsmalltalk.com/publicRepository/Epigent%20File%20In%20Method(Bundle).html
> )
>
> Runar
>  
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>  


--
Mit freundlichen Grüssen

Thomas Brodt
PORaBo Consulting
Tel. +41 71 666 76 52
Fax. +41 71 666 76 57
http://www.porabo.ch


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Epigent AlphaChannelImage

Maarten Mostert-2
In reply to this post by Runar Jordahl
Hi Runar,

I played a bit with your image and found something strange.

converting it with:  <<convertToPalette: FixedPalette rgb8Bit >>would normally modify it to your test palette, but that does not work.
However displaying it from   <<ImageReader fromFile:  'iconExample16by16.png' >> Allready shows that things turn badly:



While from finder your test icon shows correctly.



Converting the png to a 24bit bitmap shows it up correctly on both Mac and Windows but Epigent does not handle that.

Rememeber that when you use the good old icon editor reading icons from the screen gives bad result from PaintNet. You have to convert them to bitmaps open them in paint and then read them from the screen.

The real problem might originate from imageReader.

Regards,

@+Maarten,



Runar Jordahl a écrit :

I looked at this problem using an example Thomas sent me. Using the
image (provided as Smalltalk code) I reproduced the problem at 16 bit
color depth at my PC. But using my own test image, the problem does
not occur.

To get my test image inspect: AlphaChannelImage iconExample16by16image

Anyone having problems should probably look at this image and see if
it displays ok. Note how the first top-left three pixels are Red,
Green, and Blue. The PNG is attached.

What I found is that Thomas' supplied a Depth32Image that uses a
different palette than I use in my tests. Thomas' Depth32Image has
this palette:
(Graphics.FixedPalette
redShift: 16 redMask: 255
greenShift: 8 greenMask: 255
blueShift: 0 blueMask: 255)



While, my Depth32Image has this palette:
(Graphics.FixedPalette
redShift: 0 redMask: 255
greenShift: 8 greenMask: 255
blueShift: 16 blueMask: 255)

Note how my palette shifts the RGB bits in increasing order; R is at
bit position 0, G at 8, and B at 16. I am pretty sure this is causing
the problems, but I have not looked into the details of the rendering
code to confirm this. So there is a bug in the code, which I will look
at later.

The workaround is to always use a Depth32Image with the palette format
I use in my examples. To create an image I do the following:

- Edit the image in Paint.NET.
- Save the image as PNG in 32 bit format.
- Create the Depth32Image using class PNGImageReader. I use instance
method #from: where the argument is the raw PNG image file as a
Stream.

See references to method  #iconExample16by16 for the details. Note how
#iconExample16by16 answers only a ByteArray which is an exact copy of
the bytes found in the PNG file I saved from the image editing
program. This uses "Epigent File In Method". (
http://www.cincomsmalltalk.com/publicRepository/Epigent%20File%20In%20Method(Bundle).html
)

Runar
  





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Epigent AlphaChannelImage

Runar Jordahl
I think this thread highlights two different problems:

- Thomas' problem is the palette he uses. Red and Blue get mixed. As
my previous post explains, the workaround for his problem is to create
the Depth32Image from the PNG directly. To handle this problem I will
let the drawing code throw an exception when getting an invalid
palette. Later I might improve the code to handle this type of palette
too.

- Maarten's problem is not the order of the RGB values. There are two
possible explanations for his problems: 1 - The alpha (transparency)
information is not read correctly. So instead of blending with the
background, the code simply uses the color values stored in the
Depth32Image. 2 - The color value of the target image is not read
correctly, and the code always blends to a black pixel. Right now I
think explanation 1 is most likely to cause the problems.

I will add unit tests to determine the cause of Maarten's problems
(and mail you when they are ready Maarten).

Runar
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Epigent AlphaChannelImage

Rob Vens-2
Is this issue resolved somehow? Using the latest version from Store the AlphaChannelImage iconExample16by16 still shows up on my Mac as shown in the attachment.


2008/4/20 Runar Jordahl <[hidden email]>
I think this thread highlights two different problems:

- Thomas' problem is the palette he uses. Red and Blue get mixed. As
my previous post explains, the workaround for his problem is to create
the Depth32Image from the PNG directly. To handle this problem I will
let the drawing code throw an exception when getting an invalid
palette. Later I might improve the code to handle this type of palette
too.

- Maarten's problem is not the order of the RGB values. There are two
possible explanations for his problems: 1 - The alpha (transparency)
information is not read correctly. So instead of blending with the
background, the code simply uses the color values stored in the
Depth32Image. 2 - The color value of the target image is not read
correctly, and the code always blends to a black pixel. Right now I
think explanation 1 is most likely to cause the problems.

I will add unit tests to determine the cause of Maarten's problems
(and mail you when they are ready Maarten).

Runar
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

alpha.png (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Epigent AlphaChannelImage

Runar Jordahl
Can you possibly check the result of the following statement in method
AlphaChannelImage>>displayOn:at:

aGraphicsContext medium completeContentsOfArea: rectangle

Verify that temporary variable toScreenImage contains the area of the
screen to which the icon is to be drawn on. If that image is not
correct the next statement (self displayOnImage: toScreenImage.) will
of course create the wrong result image. In your case I guess
toScreenImage should contain only white pixels.

If you look at my code, you'll notice the call to
completeContentsOfArea: is covered by an exception handler. I had
problems with this method crashing. That might be caused by a bug  in
VisualWorks.

Kind regards
Runar Jordahl
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

[vwnc] List vs OrderedCollection addLast:

Henrik Sperre Johansen
In reply to this post by Rob Vens-2
addLast: in List is implemented with a check if there's a need to grow,
and a call to a privateAddLast:.
In OrderedCollection, addLast: has the same structure, but no separate
privateAddLast:.
Instead it has a addLastNoCheck: which basically does the same thing as
privateAddLast, but gets used by other methods than addLast:...
Would it perhaps be a good idea to make these two methods work the same
way?
(ie: the List way, so in OrderedCollection rename addLastNoCheck: (or
have it call privateAddLast: for compatability reasons), and have
addLast: call it)

Cheers,
Henry

 
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Epigent AlphaChannelImage

Rob Vens-2
In reply to this post by Runar Jordahl
Using AlphaChannelImage iconExample16by16.
if I set a breakpoint in the method displayOn:at: and inspect toScreenImage the following can be seen:
it is a Depth32Image with depth 24
it displays as a black rectangle
all bits in the bits array are zero

How can I determine that it is the correct area of the screen to draw on?


2008/11/12 Runar Jordahl <[hidden email]>
Can you possibly check the result of the following statement in method
AlphaChannelImage>>displayOn:at:

aGraphicsContext medium completeContentsOfArea: rectangle

Verify that temporary variable toScreenImage contains the area of the
screen to which the icon is to be drawn on. If that image is not
correct the next statement (self displayOnImage: toScreenImage.) will
of course create the wrong result image. In your case I guess
toScreenImage should contain only white pixels.

If you look at my code, you'll notice the call to
completeContentsOfArea: is covered by an exception handler. I had
problems with this method crashing. That might be caused by a bug  in
VisualWorks.

Kind regards
Runar Jordahl


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

[vwnc] Palettes

Annick
In reply to this post by Runar Jordahl
Have you any idea how to integrate an alphaChannelImage with a cairo  
graphics which uses a different palette ( FixedPalette CairoARGB32) ?
Annick Fron

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Palettes

Runar Jordahl
All magic happens in Image>>putAlphaChannelImage:at: . There are
explicitly checks that verifies the palette. If it is not supported,
an exception is thrown.

My code traverses each 4 bytes chuck used to represent a pixel (The
#bits instance variable in Image), plotting it to the destination
image.
- My code assumes the order of bytes to be Alpha, Blue, Green, and Red.
- For #cairoARGB32, the order of pixel information is Blue, Green,
Red, and Alpha.

Changing my code is possible, but right now I have not time to do it.
So I suggest making an image my code can understand. One possibility
is to swap the bits yourself, and attach the following palette to the
image:
Graphics.FixedPalette redShift: 0 redMask: 255 greenShift: 8
greenMask: 255 blueShift: 16 blueMask: 255

To swap pixels, please do something like this (not tested):
(1 to: bits size by: 4) do: [:index | | blue green red alpha|
blue := bits at: index.
green := bits at: index + 1
red := bits at: index + 2
alpha := bits at: index +3

bits at: index put: alpha
bits at: index + 1 put: blue
bits at: index + 2 put: green
bits at: index + 3 put: red]

Runar Jordahl
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Epigent AlphaChannelImage

Mark Plas
In reply to this post by Runar Jordahl
" If you look at my code, you'll notice the call to
completeContentsOfArea: is covered by an exception handler. I had
problems with this method crashing. That might be caused by a bug  in
VisualWorks."

Hi Runar,

I don't think the reason for the exception is a bug in VW. The exception occurs when you want to get the completeContentsOfArea: for a rectangular part on your window which is partially/completely covered by another application window. In that case the primitive/the OS doesn't know what is hidden behind the window and returns a bitmap that's only partially filled (I think the unknown parts are just left black). It also returns a list of rectangles that describe the parts that were left black. If you don't mind those parts being black, you can just use #contentsOfArea instead of #completeContentsOfArea:, then the exception doesn't occur anymore.

Mark

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Runar Jordahl
Sent: woensdag 12 november 2008 12:33
To: Rob Vens
Cc: [hidden email]
Subject: Re: [vwnc] Epigent AlphaChannelImage

Can you possibly check the result of the following statement in method
AlphaChannelImage>>displayOn:at:

aGraphicsContext medium completeContentsOfArea: rectangle

Verify that temporary variable toScreenImage contains the area of the
screen to which the icon is to be drawn on. If that image is not
correct the next statement (self displayOnImage: toScreenImage.) will
of course create the wrong result image. In your case I guess
toScreenImage should contain only white pixels.

If you look at my code, you'll notice the call to
completeContentsOfArea: is covered by an exception handler. I had
problems with this method crashing. That might be caused by a bug  in
VisualWorks.

Kind regards
Runar Jordahl
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

[vwnc] Patch for alphaChannelImages

Annick
In reply to this post by Runar Jordahl

Hi,

Here is a small patch to be able to display incomplete images.

AlphaChannelImage>>displayOn: aGraphicsContext at: aPoint
 
            | toScreenImage rectangle  |
 
            rectangle := aGraphicsContext clippingBounds moveBy: aGraphicsContext translation.
            rectangle extent: self extent.
 
            rectangle area positive ifFalse: [^self].
 
            [toScreenImage := aGraphicsContext medium  completeContentsOfArea:  (rectangle intersect: (0@0 extent: (aGraphicsContext medium extent)))]
                        on: Error
                        do: [:exception | ^self].
            self displayOnImage: toScreenImage.
            aGraphicsContext copyImage: toScreenImage to: aPoint

============
Besides, I was not able to translate the palettes. I managed the mask by using png : I draw on cairo, then save as png bits, and reimport the result into an alphaChannelImage.

Best regards

Annick Fron

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Patch for alphaChannelImages

Runar Jordahl
Thank you! I did not fully understand what this patch fixes. Could you
please provide some more details?

If there is an general agreement about the patch, I will include it tomorrow.

Kind regards
Runar Jordahl

2008/11/25 Annick Fron <[hidden email]>:

>
> Hi,
> Here is a small patch to be able to display incomplete images.
> AlphaChannelImage>>displayOn: aGraphicsContext at: aPoint
>
>             | toScreenImage rectangle  |
>
>             rectangle := aGraphicsContext clippingBounds moveBy:
> aGraphicsContext translation.
>             rectangle extent: self extent.
>
>             rectangle area positive ifFalse: [^self].
>
>             [toScreenImage := aGraphicsContext medium
> completeContentsOfArea:  (rectangle intersect: (0@0 extent:
> (aGraphicsContext medium extent)))]
>                         on: Error
>                         do: [:exception | ^self].
>             self displayOnImage: toScreenImage.
>             aGraphicsContext copyImage: toScreenImage to: aPoint
> ============
> Besides, I was not able to translate the palettes. I managed the mask by
> using png : I draw on cairo, then save as png bits, and reimport the result
> into an alphaChannelImage.
> Best regards
> Annick Fron
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Patch for alphaChannelImages

Runar Jordahl
In reply to this post by Annick
Thank you for providing this fix! Bundle "Epigent Graphics" 1.8
contains the fix.

Runar Jordahl
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] List vs OrderedCollection addLast:

Andres Valloud-6
In reply to this post by Henrik Sperre Johansen
AR 55950...

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Henrik Johansen
Sent: Wednesday, November 12, 2008 3:40 AM
To: [hidden email]
Subject: [vwnc] List vs OrderedCollection addLast:

addLast: in List is implemented with a check if there's a need to grow,
and a call to a privateAddLast:.
In OrderedCollection, addLast: has the same structure, but no separate
privateAddLast:.
Instead it has a addLastNoCheck: which basically does the same thing as
privateAddLast, but gets used by other methods than addLast:...
Would it perhaps be a good idea to make these two methods work the same
way?
(ie: the List way, so in OrderedCollection rename addLastNoCheck: (or
have it call privateAddLast: for compatability reasons), and have
addLast: call it)

Cheers,
Henry

 
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] List vs OrderedCollection addLast:

Henrik Sperre Johansen
For context, I stumbled upon this when trying to speed up the addAll:
removeAll: methods somewhat.
There's quite alot of places where for the batch operations'
pre/post-conditions (like enough space checks) could be more efficiently
obtained by a single operation, and then a privateAdd:/Remove: for each
object, than the "naive" way of validating once for each object added.
I quickly discovered it's somewhat painful to the above though, as
you've got to be very careful about subclasses with different
pre/post-conditions ;) super super!

Happy new year all!
Henry

Valloud, Andres wrote:

> AR 55950...
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Henrik Johansen
> Sent: Wednesday, November 12, 2008 3:40 AM
> To: [hidden email]
> Subject: [vwnc] List vs OrderedCollection addLast:
>
> addLast: in List is implemented with a check if there's a need to grow,
> and a call to a privateAddLast:.
> In OrderedCollection, addLast: has the same structure, but no separate
> privateAddLast:.
> Instead it has a addLastNoCheck: which basically does the same thing as
> privateAddLast, but gets used by other methods than addLast:...
> Would it perhaps be a good idea to make these two methods work the same
> way?
> (ie: the List way, so in OrderedCollection rename addLastNoCheck: (or
> have it call privateAddLast: for compatability reasons), and have
> addLast: call it)
>
> Cheers,
> Henry
>
>  
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>
>  
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc