Files
test/intern/ghost
Jonas Holzman 8b569bac0d Obj-C Refactor: Autoreleasepool and property dot-notation refactor
Autoreleasepool:
- Replace outdated `NSAutoreleasePool` `init`/`drain` mechanism with
  the modern `@autoreleasepool {}` block. Leading to simpler and
  cleaner code, and more flexible functions return placement.
- Add missing `autoreleasepool` in code.
  The rule being that in an MRR (Manual Retain-Release / non-automatic
  reference counting) environments, "Cocoa expects there to be an
  autorelease pool always available. If a pool is not available,
  autoreleased objects do not get released and you leak memory"
  (quote from Apple Dev Docs).
  As we cannot make safe assumptions about function call sites, and
  cannot rely on a main autoreleasepool like a standard Obj-C
  application, every piece of Objective-C code that calls any sort of
  Cocoa function should be wrapped in an `autoreleasepool {}` block for
  eventual internal `autorelease` call to be honored.
- Add missing `release` / `autorelease`, make correct MRR pairs

A next step would be to start transitioning the Blender Obj-C codebase
from MRR to automatic reference counting (ARC).

Dot-Notation:
- Use Objective-C dot notation to follow modern Objective-C practices,
  and provide a more familiar syntax to programmers coming from C/C++,
  (`foo.prop` instead of `[foo prop]` for access, `foo.prop = bar`
  instead of `[foo setProp:bar]` for setting).
- Exception for singleton class properties / methods
  (`[NSPasteboard generalPasteboard]` instead of
  `NSPasteboard.generalPasteboard`) and nested method calls that mix
  property and methods.
  (Example: [NSApp windowWithWindowNumber:[window_number integerValue]]`
   or `[view convertRectToBacking:[view bounds]]`)

When possible, or necessary, refactored functions were simplified or
refactored, in which case the Blender code style was applied. As such
there is some overlap with PR #126770, especially when it comes to const
correctness.

Due to the fact that these two refactors are quite interlinked, and for
easier reviewing / avoiding complicated merge conflicts, they're shipped
in a single PR.

Ref #126772

Pull Request: https://projects.blender.org/blender/blender/pulls/126771
2024-09-03 11:38:32 +02:00
..
2024-08-21 23:20:34 +10:00
2024-05-04 15:24:46 +10:00
2024-08-19 15:37:48 +02:00