Re: Is "-init" really needed?

[gerti-cocoadev]

> On Aug 10, 2017, at 02:18, Alastair Houghton  
> wrote:
> 
> Personally I *would* still discourage +new in favour of class-specific 
> convenience constructors because I think it’s less expressive and also less 
> consistent (e.g. +array is better, in my opinion, than +new, not least 
> because +arrayWithObjects: and others exist).

[NSArray new] := [[NSArray alloc]init]

[NSArray array] := [[[NSArray alloc]init]autorelease]

+array and friends came along with the introduction of autorelease pools, to 
replace +new with something that didn't imply ownership (the oft mentioned 
special meaning of "new" as prefix). So while with ARC they are essentially 
equivalent, previously they were not.

Gerd
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is "-init" really needed?

[gerti-cocoadev]

Unlike with Swift, in Objective-C it is to no small part the developers who 
drive how the language evolves.

+new used to be the canonical initializer in the very olden days. But then 
folks wanted a better distinction between object allocation and object 
initialization to make memory management a bit more mechanical and less hidden. 
They also came up with the concept of the "designated initializer". That was in 
the very early 80s IIRC.

This worked, but two things happened:

- having to remember designated initializers, and chaining them correctly when 
subclassing, is a tad cumbersome. It's like having to know a secret handshake 
to use an object. Further Objective-C never formally introduced syntactic 
support for a designated initializer, so eventually some people resorted to 
some weird hinting with macros. Yuk.

- ARC

So "designated initializers" became de-emphasized over time, most modern 
objects rarely use them. And ARC now makes it less important to distinguish 
between object allocation and object initialization. Hence the renaissance of 
+new. And with the advent of dot notation some (like me) even started to 
further de-emphasize that by using "MyClass.new". This is debatable I guess, 
but I like it, because it visually distracts less from the purpose of the 
surrounding code.

Just my 2 cents, and I may be completely wrong.

Gerd


> On Aug 8, 2017, at 05:13, Uli Kusterer <witness.of.teacht...@gmx.net> wrote:
> 
> On 8. Aug 2017, at 02:23, Carl Hoefs <newsli...@autonomy.caltech.edu> wrote:
>> Is the use of +new discouraged also?
> 
> Apple have gone back and forth on this AFAIR. +new was actually the 
> pre-retain/release way to create an object. So it has been discouraged since 
> ... OpenStep, I think? But it was never formally deprecated, and I'm seeing 
> it used more and more in ARC code these days.
> 
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
> http://www.zathras.de
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/gerti-cocoadev%40bitart.com
> 
> This email sent to gerti-cocoa...@bitart.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Visible difference in text: NSTextField vs drawInRect:

[gerti-cocoadev]

Did you try the

CGContextRefctx=(CGContextRef)[[NSGraphicsContext 
currentContext]graphicsPort];

CGContextSetShouldSmoothFonts(ctx,YES);

stuff inside the -drawRect: method? That is where it needs to be. Try both YES 
and NO. Should be a visible difference.

Gerd


> On Apr 11, 2017, at 10:55, Navneet Kumar <navnee...@me.com> wrote:
> 
> Hi,
> 
> Here is another image with a character in each case zoomed in using 
> ColorMeter.
> 
> http://i66.tinypic.com/2w5m795.jpg
> 
> Wishes,
> Navneet
> 
> 
>> On 11-Apr-2017, at 2:00 AM, Quincey Morris 
>> <quinceymor...@rivergatesoftware.com> wrote:
>> 
>> On Apr 10, 2017, at 11:20 , Navneet Kumar <navnee...@me.com 
>> <mailto:navnee...@me.com>> wrote:
>>> 
>>> Actually I’m using text fields for simplicity at a lot of places. And 
>>> drawInRect: at some places, in order to vertically centre the multi-line 
>>> text more conveniently.
>> 
>> Here are some possibilities to consider:
>> 
>> 1. Shadow. What happens if you don’t specify the shadow?
>> 
>> 2. Resolution. It may be that the text drawing ends up in drawing contexts 
>> with different resolution backing stores (1x vs. 2x vs. 3x).
>> 
>> 3. Size. Does the weird effect scale with point size? If you draw the text 
>> much larger, are the results much closer to each other?
>> 
>> 4. Anti-aliasing. There is some behind the scenes magic when drawing text, 
>> that determines whether it knows the background color and therefore whether 
>> it anti-aliases using the background color.
>> 
>> 5. Overlays. It’s possible that NSTextField already draws the text more than 
>> once, to give a partial outline effect that increases contrast with 
>> mid-level color backgrounds.
>> 
>> 6. Traits. NSTextField may be opting into the trait behavior that classifies 
>> text as Body, Headline, Caption, etc. These things might cause some 
>> adjustment to the font weight. Or the accessibility features that change the 
>> font appearance. (But I’m not sure which of those is available on macOS.)
>> 
>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/gerti-cocoadev%40bitart.com
> 
> This email sent to gerti-cocoa...@bitart.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Visible difference in text: NSTextField vs drawInRect:

[gerti-cocoadev]

This may or may net help:

CGContextRefctx=(CGContextRef)[[NSGraphicsContext 
currentContext]graphicsPort];

CGContextSetShouldSmoothFonts(ctx,YES);

Gerd

> On Apr 10, 2017, at 09:41, Navneet Kumar <navnee...@me.com> wrote:
> 
> Hi,
> 
> There is visible difference in text when setting the same string, same font, 
> same text colour to a text field.
> And when the same is done via NSString drawInRect method having same 
> attributes for text.
> 
> The image URL to a sample image: http://i63.tinypic.com/xbe0bc.jpg
> 
> The top text is using a text field and bottom text is using drawInRect:.
> 
> The rect supplied to drawInRect: is many time bigger than needed.
> 
> I have both ways implemented in my project, so would it be possible to make 
> drawInRect: draw as boldly as a text field?
> 
> Is there any other neater, more consistent way to draw text?
> 
> Thanks,
> Navneet
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/gerti-cocoadev%40bitart.com
> 
> This email sent to gerti-cocoa...@bitart.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to keep things alive in Arc?

[gerti-cocoadev]

This was recommended to me by folks "in the know":

Thing *aThing = [ Thing new ];

...

(void)aThing;

Gerd



> On May 8, 2016, at 21:11, Gerriet M. Denkmann <gerr...@mdenkmann.de> wrote:
> 
> Thing *aThing = [ Thing new ];
> 
> void *thingData = [ aThing data ];//  pointer to a buffer owned by 
> aThing
> 
> … never use aThing after this point → Arc might release aThing right now
> … but do lots of things with thingData
> 
> … no more need for thingData
> [ aThing release];
> 
> How to prevent Arc to release aThing before I have done with thingData?
> 
> Gerriet.
> 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/gerti-cocoadev%40bitart.com
> 
> This email sent to gerti-cocoa...@bitart.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com